Understanding Database Transactions, ACID Properties, Isolation Levels, and Spring Transaction Management

Transaction Concept

A transaction is a logical unit of work in a database management system, consisting of a finite sequence of database operations that must either all succeed or all fail, ensuring data integrity.

Transaction Properties (ACID)

A transaction must satisfy the ACID properties: Atomicity, Consistency, Isolation, and Durability.

Atomicity: All operations are executed as an indivisible whole; if any operation fails, the entire transaction fails.

Consistency: The database moves from one consistent state to another, preserving integrity constraints.

Isolation: Concurrent transactions do not interfere with each other.

Durability: Once committed, the changes are permanently stored and cannot be rolled back.

Isolation Levels

Four isolation levels are defined, from weakest to strongest:

Read Uncommitted

Read Committed

Repeatable Read

Serializable

Concurrent transaction anomalies such as dirty reads, non‑repeatable reads, and phantom reads can occur depending on the chosen level.

Typical defaults: most databases use Read Committed (e.g., SQL Server, Oracle), while MySQL defaults to Repeatable Read .

Spring Transaction Propagation

Spring defines seven propagation behaviors that control how transactions are created or joined:

PROPAGATION_REQUIRED: Join existing transaction or start a new one if none exists.

PROPAGATION_SUPPORTS: Join if a transaction exists; otherwise execute non‑transactionally.

PROPAGATION_MANDATORY: Must join an existing transaction; otherwise throw an exception.

PROPAGATION_REQUIRES_NEW: Always start a new transaction, suspending any existing one.

PROPAGATION_NOT_SUPPORTED: Execute non‑transactionally and suspend any existing transaction.

PROPAGATION_NEVER: Execute non‑transactionally; throw an exception if a transaction is active.

PROPAGATION_NESTED: Execute within a nested transaction if a transaction exists; otherwise behave like REQUIRED.

Special notes: NESTED requires a JDBC 3.0 driver and the transaction manager’s nestedTransactionAllowed flag set to true; REQUIRES_NEW often needs a JTA transaction manager.

Spring Transaction Isolation Levels

Spring maps the standard JDBC isolation levels:

ISOLATION_DEFAULT – uses the database’s default level.

ISOLATION_READ_UNCOMMITTED – allows reading uncommitted changes (lowest level).

ISOLATION_READ_COMMITTED – prevents dirty reads; data is visible only after commit.

ISOLATION_REPEATABLE_READ – prevents dirty and non‑repeatable reads; may still allow phantom reads.

ISOLATION_SERIALIZABLE – highest level; eliminates dirty reads, non‑repeatable reads, and phantom reads.

Spring Transaction Architecture

The Spring transaction framework separates transaction management from data access through three core interfaces:

PlatformTransactionManager – defines transaction boundaries.

TransactionDefinition – specifies attributes such as isolation level and propagation behavior.

TransactionStatus – represents the current state of a transaction.

Implementations include DataSourceTransactionManager for JDBC/MyBatis, HibernateTransactionManager for Hibernate, and JtaTransactionManager for global transactions.

Using Spring for Transaction Management

Configuration

Programmatic transactions – use TransactionTemplate or directly interact with PlatformTransactionManager .

Declarative transactions – rely on AOP and the @Transactional annotation or XML tx namespace.

Declarative transactions keep business code clean, applying transaction rules automatically before and after method execution. While they operate at method level, developers can still achieve finer granularity by extracting transactional code into separate methods.

For further reading, see the linked articles on MVCC principles, ByteDance work experience, MySQL indexing and optimization, Redis caching, and distributed locks.