Read Committed Isolation

Read Committed isolation ensures a transaction does not read changes made by another transaction until those changes are committed. It prevents dirty reads, while still allowing the same query to observe newer committed data later in the transaction.

Read Committed is a transaction isolation level commonly supported by relational databases. When transaction A changes a row but has not committed, transaction B cannot read that uncommitted version of the row.

The important limitation is that Read Committed does not guarantee that repeated reads return the same value. If transaction B reads a row, transaction A then commits an update, and B reads the row again, B may see the updated value. This behavior is called a non-repeatable read.

The exact implementation depends on the database. Some systems use locks, while others use multi-version concurrency control (MVCC). With MVCC, a reader can often access an appropriate committed row version without blocking a concurrent writer.

For a Java backend engineer, the isolation level is normally configured at the database or transaction layer rather than implemented manually in application code. In JDBC, for example, `Connection.TRANSACTION_READ_COMMITTED` represents this isolation level.

Key points

• Dirty reads are prevented.
• A transaction can observe newly committed changes during its lifetime.
• Non-repeatable reads can occur.
• Implementation details vary between database systems.
• In JDBC, the standard constant is `TRANSACTION_READ_COMMITTED`.

Interview questions

What does Read Committed isolation mean?

It means a transaction can only read data that another transaction has committed. If another transaction has changed a row but has not committed, that uncommitted change is not visible. This prevents dirty reads. However, later reads in the same transaction can see changes that other transactions committed after the earlier read.

Can two reads in the same Read Committed transaction return different values?

Yes. Suppose transaction A reads a row and transaction B then updates and commits that row. If A reads the row again, the second read can observe B's committed update. This is a non-repeatable read. Therefore, Read Committed protects against dirty reads but does not necessarily provide a stable snapshot for the entire transaction.

How does Read Committed relate to MVCC?

MVCC maintains multiple versions of data so readers can select a version that satisfies the isolation rules without necessarily blocking writers. Under a typical Read Committed implementation, each statement may use a view containing data committed when that statement begins. The precise behavior is database-specific, so the database's documentation matters. Read Committed therefore describes the visibility guarantee, while MVCC describes one possible implementation technique.

What anomaly does Read Committed allow that Repeatable Read addresses?

Read Committed can allow a non-repeatable read. A transaction may read a row, another transaction may update and commit it, and the first transaction may then read a different value for the same row. Repeatable Read provides stronger guarantees for repeated reads. The exact guarantees and implementation details can vary by database.

How would you configure Read Committed in JDBC?

JDBC exposes Read Committed through `Connection.TRANSACTION_READ_COMMITTED`. An application can request it with `setTransactionIsolation` on a database connection, assuming the database and driver support that isolation level. The actual transaction behavior is still determined by the database implementation. Applications should also understand the database's default isolation level rather than assuming it.