How To Deal With Transaction Isolation Levels?

Transaction Isolation is the "I" in ACID and defines the visibility of changes in concurrent transactions. Serializable is the highest value and ensures absolute consistency. Read Uncommitted provides the highest concurrency with low consistency. NONE comes with no consistency and indicates the lack of transaction support.

Isolation Levels can be set on java.sql.Connection level. In a Java EE environment isolation levels can be configured on Data Source / Connection Pool (see e.g. Glassfish).

The transaction consistency does influence the business logic and has to be discussed with domain experts.

A low risk approach to set a proper Isolation Level is:

  1. Set the highest possible Isolation Level (Serializable)
  2. Perform Stress Tests and measure the impact
  3. If the required throughput / performance cannot be met or deadlock occurs, escalate the problem, talk to domain experts and either change the business logic, or lower the Isolation Level

Thanks Pavan Madiraju for the question!

[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 19 in, chapter "The Concurrency Problem"]

See you at Java EE Workshops at MUC Airport--consistency, concurrency and persistence are discussed until no questions are left :) !


Hi Adam,

Why do you set the isolation level to SERIALIZABLE?

The standard isolation level READ_COMMITED and that works for 99.9% of all cases.


Posted by Simon Martinelli on March 21, 2013 at 01:54 PM CET #

If using a database which supports Multiversion Concurrency Control, such as Oracle (and many others), Read Committed is a reasonable default.

Posted by Danilo Piazzalunga on March 21, 2013 at 09:22 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments