Tags

, ,


READ COMMITTED

Specifies that shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

READ UNCOMMITTED

Implements dirty read, or isolation level 0 locking, which means that no shared locks are issued and no exclusive locks are honored. When this option is set, it is possible to read uncommitted or dirty data; values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the four isolation levels.

REPEATABLE READ

Locks are placed on all data that is used in a query, preventing other users from updating the data, but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction. Because concurrency is lower than the default isolation level, use this option only when necessary.

SERIALIZABLE

Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.

Now what are Phantom reads:

At the time of execution of a transaction, if two queries that are identical are executed, and the rows returned are different from one another, it is stated that a phantom read occurred. The possibility of occurring phantom reads is when the range locks are not acquired by the execution of SELECT.

So how to maintain this in Hibernate :

Transaction Summary : Usually, you use read committed isolation for database transactions, together with optimistic concurrency control (version and timestamp checking) for long application transactions.
Hibernate greatly simplifies the implementation of application transactions
because it manages version numbers and timestamps for you.

In Hibernate we can use :

LockMode PESSIMISTIC_FORCE_INCREMENT
Transaction will immediately increment the entity version.
LockMode OPTIMISTIC_FORCE_INCREMENT  : Optimisticly assume that transaction will not experience contention for entities.
Advertisements