Hibernate isolation levels

Isolation Level       Dirty Read    Nonrepeatable Read  Phantom Read  
READ UNCOMMITTED      Permitted       Permitted           Permitted
READ COMMITTED              --        Permitted           Permitted
REPEATABLE READ             --             --             Permitted
SERIALIZABLE                --             --              --

READ UNCOMMITTED - no lock on table
READ COMMITTED - lock on committed data
REPEATABLE READ - lock on block of sql(which is selected by using select query)
SERIALIZABLE - lock on full table(on which Select query is fired)

Using Hibernate:
<property name="hibernate.connection.isolation">2</property>

Where

1: READ UNCOMMITTED
2: READ COMMITTED
4: REPEATABLE READ
8: SERIALIZABLE




below are the three phenomena which can occur in transaction isolation 
Dirty Read- no lock 
Nonrepeatable Read - no dirty read as lock on committed data 
Phantom Read - lock on block of sql(which is selected by using select query)

Dirty Reads: Occurs when a transaction reads data modified by other concurrent processes that have not yet committed, so it is called dirty reading. 

Nonrepeatable Reads:It happens when within a transaction the same record is read more than once and the data obtained are different, probably because another concurrent process updated them. 

Phantom Reads: It happens when in a transaction we execute the same query more than once and we obtain different results, for example if another transaction added new records that satisfy the search criteria of the query. 

The ANSI / ISO SQL standard defines four isolation levels: 

READ UNCOMMITTED: Allows Dirty Reads, Nonrepeatable Reads and PhantomReads to be produced. It is the least restrictive option, recommended if read-only data or very few updates are handled. 

READ COMMITTED:Avoid Dirty Reads, but allow Nonrepeatable Reads and Phantom Reads to occur. 

REPEATABLE READ: Only allows Phantom Reads to be produced. 

SERIALIZABLE: Avoid all previous cases, it is the most restrictive option. 

For example, you have 3 concurrent process A, B and C. A starts a transaction, writes data and commit/rollback (depending on results). B just executes a SELECT statement to read data. C reads and updates data. All these process work on same table T.

READ UNCOMMITTED - no lock on table. You can read data in the table while writing on it. This means, A writes data (uncommited) and B can read this uncommited data and use it (for any purpose). If A executes a rollback, B still has read the data and used it. This is the fastest but most insecure way to work with data since can lead to data holes in not physically related tables (yes, two tables can be logically but not physically related in real world apps =\).
READ COMMITTED - lock on committed data. You can read the data that was only commited. This means, A writes data and B can't read the data saved by A until A executes a commit. The problem here is that C can update data that was read and used on B and B client won't have the updated data.
REPEATABLE READ - lock on block of sql(which is selected by using select query). This means, B reads the data under some condition i.e. WHERE aField > 10 AND aField < 20, A inserts data where aField value is between 10 and 20, then B reads the data again and get a different result.
SERIALIZABLE - lock on full table(on which Select query is fired). This means, B reads the data and no other transaction can modify the data on the table. This is the most secure but slowest way to work with data. Also, since a simple read operation locks the table, this can lead to heavy problems on production: imagine that T table is an Invoice table, user X wants to know the invoices of the day and user Y wants to create a new invoice, so while X executes the read of the invoices, Y can't add a new invoice (and when it's about money, people get really mad, specially the bosses).






Examples







The following example sets the TRANSACTION ISOLATION LEVEL for the session. For each Transact-SQL statement that follows, SQL Server holds all of the shared locks until the end of the transaction.










SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
GO
BEGIN TRANSACTION;
GO
SELECT * 
    FROM HumanResources.EmployeePayHistory;
GO
SELECT * 
    FROM HumanResources.Department;
GO
COMMIT TRANSACTION;
GO