Isolation Levels

Isolation is a property that defines how and when a change made by one operation becomes visible to other concurrent operations. Isolation is one of the ACID (Atomicity, Consistency, Isolation, and Durability) properties as discussed earlier in this chapter. Isolation levels are commonly used in database systems to describe how locking is applied to data within a transaction.

Before going to the various isolation levels, I would like to introduce you to database locks as these are key concepts in understanding isolation levels to greater extend.  There are three types of database locks possible and they are:

• Read Locks – these locks prevent other transactions from changing data read during a transaction until the transaction ends, thus preventing non-repeatable reads. Other transactions can read the data but not write to it. The current transaction is also prohibited from making changes. Whether these locks only the records read, a block of records, or a whole table depends on the database being used (completely vendor specific implementation).
• Write Locks – These locks are used for updates. This lock prevents other transactions from changing the data until the current transaction is complete but allows dirty reads by other transactions and by the current transaction itself. In other words, the transaction can read its own uncommitted changes.
• Exclusive Write Locks – These locks are also used for updates. An exclusive write lock prevents other transactions from reading or changing the data until the current transaction is complete. It also prevents dirty reads by other transactions. Some databases do not allow transactions to read their own data while it is exclusively locked. Again implementations are vendor specific and you should consult vendor documentation to get a clear picture.

Of the four ACID properties in a DBMS (Database Management System), the isolation property is the one most often relaxed. When attempting to maintain the highest level of isolation, a DBMS usually acquires locks on data which results in loss of concurrency. Most DBMS offers a number of transaction isolation levels, which control the degree of locking that occurs when selecting the data.

The isolation levels defined by the ANSI/ISO SQL standard are listed as follows:

• Serializable
• Repeatable Reads
• Read Committed
• Read Uncommitted

The following sections cover these isolation levels in detail.

Serializable

This is the highest isolation level which can be applied to a transaction. If this isolation level is applied transactions are perfectly isolated from each other. That is, nothing that one transaction does can affect any other transaction until the transaction is committed. The effect is as if all transactions were executed one after the other. Applying this isolation level lets you exclusive read and update privileges; different transactions can neither read nor write to the same data. Dirty reads, non-repeatable reads, and phantom reads are prevented by using this isolation level.

Repeatable Reads

Every time a transaction reads or updates the database, a read or write lock is obtained and held until the end of the transaction. This provides almost perfect isolation. Transaction with this isolation level cannot change data that is being read by a different transaction. Dirty reads and non-repeatable reads are prevented; phantom reads can occur.

Read Committed

Read locks are not held until the end of a transaction. So, repeated reads can give different answers and causes updates committed by other transactions visible to an ongoing transaction. The transaction cannot read uncommitted data; data that is being changed by a different transaction cannot be read. Dirty reads are prevented; non-repeatable reads and phantom reads can occur.

Read Uncommitted

Neither read locks nor write locks are held until the end of a transaction. The transaction can read uncommitted data i.e., data changed by a different transaction that is still in progress. Dirty reads, non-repeatable reads, and phantom reads can occur. This is the lowest isolation level.

Transaction Propagation

Transaction propagation defines how transaction manager handles transaction in your Spring application.

The Java platform supports six types of transaction attributes. They are:

• Required – This attribute means that the method must be invoked within the scope of a transaction. If the calling client is part of a transaction, it is automatically included in its transaction scope. If, however, the calling client is not involved in a transaction, it starts its own new transaction and continues execution. In any case this method will only be executed within a transaction.
• Mandatory – This attribute means that the method must always be made part of the transaction scope of the calling client. The method may not start its own transaction; the transaction must be propagated from the client. If the calling client is not part of a transaction, the invocation will fail, throwing appropriate exception.
• RequiresNew – This attribute means that a new transaction is always started. Regardless of whether the calling client is part of a transaction, a method with this attribute begins a new transaction when invoked. If the calling client is already involved in a transaction, that transaction is suspended until the method call returns.
• Supports – This attribute means that the method will be included in the transaction scope if it is invoked within a transaction. The client invoking a method marked with this attributes becomes part of the original transaction.
• NotSupported – Invoking a method with this transaction attribute suspends the transaction until the method is completed. This means that the transaction scope is not propagated further. Once the method with this transaction attribute completes, the original transaction resumes its execution.
• Never – This attribute means that the method must not be invoked within the scope of a transaction. If the calling client is part of a transaction, it will throw appropriate exception indicating the same. However, if the calling client is not involved in a transaction, it will execute normally without a transaction.

Page Visitors: 9643

The following two tabs change content below.

• Bio
• Latest Posts

Tomcy John

Blogger & Author at javacodebook

He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently working as Principal Architect at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Architect to facilitate incorporating Spring as Corporate Standard in the organization.

Latest posts by Tomcy John (see all)

• A Guide to Continuous Improvement for Architects - February 2, 2023
• Cloud-first Architecture Strategy - January 26, 2023
• Architecture Strategy and how to create One - January 24, 2023