Transaction isolation in hibernate

In our project, we often find that the Program Reports sesssion is closed or the current transaction cannot be committed because the data has been modified by other transactions. Because the system runs for dozens of users at most, therefore, we consider using strict transaction isolation to prevent this type of problem. The session is closed issue may not be completely solved (we suspect that the jbpm used in the project has a bug ).

1. transaction isolation

Transaction isolation means that for a running transaction, it seems that there is only one transaction in the system, and other concurrent transactions do not exist. In most cases, fully isolated transactions are rarely used. However, incomplete isolation of transactions can cause the following problems.

Lost update: both transactions attempt to update a row of data, causing the transaction to throw an exception and exit. The updates of both transactions are in vain.

Dirty data (dirty read): If the second application uses the data modified by the first application and the data is in the uncommitted state, dirty read occurs. The first application may then request to roll back the modified data, resulting in data corruption in the second transaction, that is, the so-called "dirty ".

Unrepeatable read: A transaction reads the same row of data twice, but the data read these two times is different. If a transaction can modify or delete the data before committing the data, it cannot be re-viewed.

Phantom read: A transaction executes two queries and finds that the second query result is one more row than the first query, this may be because another transaction inserts a new row between the two queries.
In view of the above problems caused by incomplete isolation of transactions, some isolation levels are proposed to prevent these problems.

Read uncommitted: indicates that a transaction is visible to other transactions before it is committed. In this way, dirty reads, unrepeatable reads, and Phantom reads are allowed. When a transaction has written a row of data but has not been committed, other transactions cannot write this row of data. However, any transaction can read any data. This isolation level is implemented using a write lock.

Read committed: it is not allowed to read uncommitted data. It is implemented using temporary read locks and write locks. Dirty reads are not allowed at this isolation level, but repeat and Phantom reads are not allowed.

Repeatable read: the transaction ensures that the same data can be read again without failure. This isolation level does not allow dirty reads and unrepeatable reads, but Phantom reads will appear.

Serializable: Provides the strictest transaction isolation. This isolation level does not allow concurrent transaction execution, but serial execution. In this way, dirty reads, unrepeatable reads, or Phantom reads can occur.

The relationship between transaction isolation and isolation level is shown in Table 9-2.

Table 9-2 Relationship between transaction isolation and isolation level

Separation level
Dirty read)
Unrepeatable read)
Phantom read)
 
Read uncommitted)
Possible
Possible
Possible
 
Read committed)
Impossible
Possible
Possible
 
Repeatable read)
Impossible
Impossible
Possible
 
Serializable)
Impossible
Impossible
Impossible
 

In a real application, developers often cannot determine the isolation level to use. Too strict level will reduce the performance of concurrent transactions, but not enough isolation level will produce some small bugs, and these bugs will only be overloaded by the system (that is, when the concurrency is serious).

In general, read uncommitted is dangerous. The rollback or failure of one transaction will affect another parallel transaction, or leave data inconsistent with the database in the memory. The data may be read by another transaction and committed to the database. This is totally not allowed.

In addition, most programs do not need serializable isolation ). Although it does not allow phantom reading, phantom reading is generally not a big problem. Serializable isolation requires a lot of system expenses, and few people use this transaction isolation mode in actual development.

The available isolation levels are read committed and Repeatable read ). Hibernate supports Repeatable read isolation.

2. Set the isolation level in the hibernate configuration file

JDBC uses the default isolation level to connect to the database, that is, Read committed and Repeatable read ). In the hibernate configuration file hibernate. properties, you can modify the isolation level:

# Hibernate. Connection. Isolation 4

In the previous line of code, the isolation level of the hibernate transaction is 4. What does this mean? The value of the level is as follows.

1: Read uncommitted)
2: Read committed)
4: Repeatable read)
8: serializable)

Therefore, number 4 indicates the "repeatable" isolation level. To make the preceding statement valid, remove the annotator "#" before the statement line:

Hibernate. Connection. Isolation 4
 
You can also add the following code to the configuration file hibernate. cfg. xml:
<Session-factory> ..... // Set the isolation level to 4 <property name = "hibernate. Connection. Isolation"> 4 </property> ...... </Session-factory>

Before starting a transaction, Hibernate obtains the isolation level value from the configuration file.

This article is from the csdn blog. For more information, see file: // C:/Documents % 20and % 20 settings/WINZ/desktop/hibernate的 20-20-20-20-20-20csdn .htm.