Java Reference
In-Depth Information
Isolation Level
Dirty Read
Non-Repeatable Read
Phantom Read
Read Uncommitted
YES
YES
YES
Read Committed
NO
YES
YES
Repeatable Read
NO
NO
YES
Serializable
NO
NO
NO
From Table 4 -1 , you can see that if Read Committed is supported, you will never
experience a DIRTY READ, but you might experience a NON-REPEATABLE READ
or a PHANTOM READ. Similarly, if Repeatable Read is supported, you will never
experience a DIRTY READ or a NON-REPEATABLE READ, but you might
experience a PHANTOM READ.
Table 4 -1 lists isolation levels in terms of the level of isolation afforded, in that Read
Uncommitted is less restrictive than Read Committed. Typically, the higher the level
of isolation, the greater the locking overhead and the lower the concurrency between
users, so the slower the application executes. This means a trade off occurs between
performance and data consistency when making a decision about what isolation level
to use.
The current level of isolation can be queried using this method:
public int getTransactionIsolation()
This method returns the following isolation level codes:
 
TRANSACTION_NONE: Transactions are not supported.
 
TRANSACTION_READ_COMMITTED: Dirty reads are prevented; nonrepeatable reads and
phantom reads can occur.
 
TRANSACTION_READ_UNCOMMITTED: Dirty reads, nonrepeatable reads, and phantom
reads can occur.
 
TRANSACTION_REPEATABLE_READ: Dirty reads and nonrepeatable reads are prevented;
phantom reads can occur.
 
TRANSACTION_SERIALIZABLE: Dirty reads, nonrepeatable reads, and phantom reads are
prevented.
Control over the isolation level of a connection is provided by this method:
con.setTransactionIsolation(TRANSACTION_ISOLATION_LEVEL_XXX);
For example, you can instruct the DBMS to allow a value to be read before it has
been committed with the following code:
con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
Search WWH ::




Custom Search