Hibernate database transaction and Isolation level __ Database

Database Transactions: A business is a group of interdependent actions, such as bank transactions, stock transactions, or online shopping. The success of a transaction depends on whether all of these interdependent actions can be performed successfully, as long as one action failure fails, which means the entire transaction fails. A classic example of a transaction is: A to the bank for transfer transactions, the 100 yuan to the account of B, this transaction contains the following actions:

(1) Subtract 100 yuan from the account of a.

(2) Add $100 to account B.

Obviously, the above two operations must be an indivisible unit of work. If only the first step of the operation succeeded, so that Tom's account deducted 100 yuan, but the second operation failed, Jack's account did not increase 100 yuan, then the entire transaction failed. A database transaction is a simulation of real-life transactions, consisting of a set of SQL statements that depend on each other in business logic.

Let's take a look at the lifecycle of the database transaction:

The life cycle diagram of this database transaction reflects the three boundaries of the database transaction:

1. Start boundary of the transaction.

2. Normal end boundary of a transaction (commit): Commits a transaction, permanently saving the database state after the transaction has been updated.

3. The exception end boundary of the transaction (ROLLBACK): revokes the transaction, returning the database to its initial state before the transaction was performed.

In fact, each database connection has a global variable @ @autocommit, which represents the current transaction mode, which has two optional values: 0: Manual commit mode. 1: Default value, indicates autocommit mode .

In autocommit mode, each SQL statement is a separate transaction. That is, every time a SQL statement is executed, the database will automatically commit the transaction, and when we use another client of the database to query, we can see the newly modified or inserted data. In manual commit mode, you must explicitly specify the transaction start and end boundaries:

– Start boundary of transaction: Begin

– Commit TRANSACTION: Commit

– Undo transaction: Rollback

Let's take a look at how the transaction boundary is declared through the JDBC API:

Connection provides the following methods for controlling transactions:

1.setAutoCommit (Boolean autocommit): Set whether the transaction is automatically committed

2.commit (): Commit Transaction

3.rollback (): Undo Transaction

Let's take a look at the specific application examples:

[Java] view plain copy print try {    con =  Java.sql.DriverManager.getConnection (DBURL,DBUSER,DBPWD);   //Set manual COMMIT Transaction Mode     Con.setautocommit (False);    stmt = con.createstatement ();   //Database Update operation 1     stmt.executeupdate ("update accounts set balance=900 where id=1   ");   //Database update operation 2    stmt.executeupdate (" update accounts set  balance=1000 where id=2  ");    con.commit ()  //Commit transaction    }catch ( exception e)  {    try{    Con.rollback (); Undo transaction    If  //operation is unsuccessful  }catch (EXCEPTION EX) {   //Handling exception     ......   }    //Handling exception     ......   }finally{...}    

Seeing the example above, we can see that the hibernate transaction boundary is actually the transactional boundary of the copycat JDBC, in fact, the transaction management at the bottom of the hibernate is the use of JDBC. Let's take a look at the Hibernate transaction boundary:

1. Declare the start boundary of the transaction:

Transaction tx=session.begintransaction ();

2. Submission of services: Tx.commit ();

3. Revocation of affairs: Tx.rollback ();

When we are learning JDBC database transaction management, the focus is also difficult to learn jdbc multiple transaction concurrency problems . Since the hibernate is implemented with JDBC transaction management, it must also have multiple transactional concurrency problems. Let's look at the following: Hibernate concurrency Problems with multiple transactions:

• First Class loss update: When you undo a transaction, overwrite the updated data that was submitted by the other transaction.

• Dirty reads: One transaction reads the uncommitted update data for another transaction.

• Virtual read: A transaction reads a newly inserted data that has been committed by another transaction.

• Non-repeatable reads: One transaction reads an updated data that has been committed by another transaction.

• Second Class loss update: This is a special case in non-repeatable reads, one transaction overwrites the updated data that has been committed by another transaction.

Here's a dirty read to give an example:

Withdrawals in the T5 time to change the deposit balance to 900 yuan, the cheque transfer business at T6 time to check the balance of the account is 900 yuan, the withdrawal of the transaction at T7 moment was revoked, the cheque transfer business at the T8 time to change the balance of deposits to 1000 yuan. Because the cheque Transfer transaction inquires to the withdrawal transaction not to submit the update data, and carries on the update operation based on this query result, if the withdrawal transaction finally is withdrawn, can cause the bank customer to lose 100 yuan.

Transaction ISOLATION Level

For the transaction isolation level, let's take a look at the following two illustrations:

As can be seen from the above illustration: the higher the isolation level, the greater the assurance of data integrity and consistency, but the greater the impact on concurrency performance. For most applications, it is preferable to set the isolation level of the database system to read committed, which avoids dirty reads and has better concurrency performance. Although it can result in the concurrency problems of non repeatable read, virtual read, and second class loss updates, the application can be controlled by pessimistic locks or optimistic locks on individual occasions where such problems may occur.

Let's take a look at hibernate how to configure the isolation level: You can explicitly set the isolation level in a Hibernate configuration file. Each isolation level corresponds to an integer:

1:read UNCOMMITTED

2:read committed

4:repeatable Read

8:serializable

For example, the following code sets the isolation level in the Hibernate.cfg.xml file to read committed:

hibernate.connection.isolation=2

For each connection obtained from the database connection pool, hibernate will change it to use the Read Committed isolation level.

Reprint Address: http://blog.csdn.net/csh624366188/article/details/7627693