Database Transactions Demystified: ACID, Isolation Levels & Spring Propagation

ACID properties form the foundation of reliable database transactions. They consist of Atomicity (all‑or‑nothing execution), Consistency (data remains valid after a transaction), Isolation (concurrent transactions do not interfere), and Durability (committed changes survive crashes).

Isolation levels define how strictly a database isolates concurrent transactions. The four standard levels are:

READ_UNCOMMITTED – lowest isolation, highest concurrency, allows dirty reads.

READ_COMMITTED – prevents dirty reads, still permits non‑repeatable and phantom reads.

REPEATABLE_READ – prevents dirty and non‑repeatable reads, but phantom reads may occur.

SERIALIZABLE – highest isolation, eliminates all three anomalies at the cost of reduced concurrency.

Understanding these levels helps choose the right balance between performance and data integrity.

Common concurrency anomalies :

Dirty Read : Transaction A reads uncommitted changes from Transaction B, leading to inconsistent data. Example shown in the first diagram where a balance appears as 0 ¥ instead of the correct 1500 ¥.

Non‑repeatable Read : Transaction A reads a row, Transaction B modifies and commits it, and a subsequent read by A returns a different value. Illustrated in the second diagram where a balance changes from 1000 ¥ to 0 ¥.

Phantom Read : Transaction A re‑executes a query and sees newly inserted rows committed by Transaction B, causing aggregate results to change. The third diagram demonstrates varying total deposits due to concurrent inserts.

These anomalies are mitigated by selecting an appropriate isolation level; the accompanying matrix (fourth image) maps each level to the anomalies it prevents.

In Java, the java.sql.Connection interface exposes these levels. You can query the default isolation of a database with:

DatabaseMetaData meta = DBUtil.getDataSource().getConnection().getMetaData();
int defaultIsolation = meta.getDefaultTransactionIsolation();

JDBC drivers map the four levels to constants such as Connection.TRANSACTION_READ_COMMITTED. MySQL defaults to READ_COMMITTED, while Oracle, SQL Server, and DB2 have their own defaults.

Spring Framework extends JDBC transaction management with transaction propagation behaviors . Spring defines seven propagation types:

PROPAGATION_REQUIRED (default) – join existing transaction or create a new one.

PROPAGATION_REQUIRES_NEW – always start a new transaction, suspending any existing one.

PROPAGATION_NESTED – execute within a nested transaction that commits/rolls back with the outer transaction.

PROPAGATION_SUPPORTS – execute non‑transactionally if none exists, otherwise join.

PROPAGATION_NOT_SUPPORTED – suspend any existing transaction and run non‑transactionally.

PROPAGATION_NEVER – throw an exception if a transaction exists.

PROPAGATION_MANDATORY – throw an exception if no transaction exists.

Choosing the correct propagation ensures that transactional boundaries align with business logic across method calls.

Spring also offers auxiliary features:

Transaction timeout – automatically roll back if a transaction exceeds a configured duration.

Read‑only transactions – hint the database that the transaction will not modify data, allowing optimizations.

Configuration can be done via XML ( <tx:annotation-driven />) or, more commonly, using annotations such as @Transactional on methods, where isolation level, propagation, timeout, and read‑only flags are specified.

By understanding ACID principles, selecting the proper isolation level, and leveraging Spring’s propagation and supplemental settings, developers can build robust, high‑performance data‑centric applications.