Hibernate Transaction Management

A. transaction consists of four basic features: for short, acid:

1. Atomic (atomicity): All successful or all failed;

2. Consistency (consistency): Only valid data can be written, the rule of law rollback to the original state;

3. Isolation (Isolation): Allow concurrency, concurrent transactions are independent of each other;

4. Durability (persistent): After the end of the transaction, the result can be saved;

Two. database Transaction management isolation LEVEL

Three types of uncertainties often occur during database operations:

1. Dirty Read (Dirty Reads): One transaction reads uncommitted data from another parallel transaction;

2. Non-repeatable read (non-repeatable Reads): When a transaction reads the data that has been read again, it finds that the data has been modified by another committed transaction;

3. Virtual read (Phantom Reads): A transaction re-executes a query that returns a set of records that meet the query criteria, but these records contain new records resulting from other recently committed transactions;

To avoid the above three cases, the following four types of transaction isolation levels are defined:

Isolation level	Dirty Read	Non-REPEATABLE READ	Virtual Read
Read UNCOMMITTED	possible	possible	possible
Read committed	No way	possible	possible
Repeatable Read	No way	No way	possible
Serialiazble	No way	No way	No way

The severity of these four transaction isolation levels is increased from the point of travel, and the performance is decreased in turn.

Three. Overview of transaction management

Hibernate is a lightweight package of JDBC and does not have transaction management capabilities in itself. At the transaction management level, Hibernate entrusts it to the underlying JDBC or JTA for transaction management and scheduling.

1. JDBC-based transaction management

Look at the following code:

Session = Sessionfactory.opensession ();

Transaction tx = Session.begintransaction ();

......

Tx.commit ();

It is important to note that in Sessionfactory.opensession (), Hibernate initializes the database connection, and at the same time, Set its autocommit to the off state (false). And then, in the Session.begintransaction method, Hibernate will reconfirm the Connection The Autocommit property is set to OFF (to prevent user code from modifying the Connection.autocommit property of the session).

That is to say, when we started the session from Sessionfactory, its Autocommit property was closed (Autocommit=false), and the following code would not have any effect on the transactional database, except for non-transactional databases, such as MySQL ISAM):

Session = Sessionfactory.opensession ();

Session.save (user);

Session.close ();

This is actually equivalent to the Autocommit property of the JDBC connection is set to false, and after performing several JDBC operations, no call to commit operation is imminent connection shutdown.

To use code to really work with the database, we must explicitly invoke the transaction directive:

Session = Sessionfactory.opensession ();

Transaction tx = Session.begintransaction ();

Session.save (user);

Tx.commit ();

Session.close ();

2. JTA-based transaction management

JTA provides cross-session transaction management capabilities. This is the biggest difference from JDBC transaction.

The JDBC transaction is managed by connection, which means that transaction management is actually implemented in the JDBC connection. Transaction cycles are limited to the life cycle of connection.

The JTA transaction management is implemented by the JTA container, and the JTA container dispatches the many connection of the current join transaction to realize its transactional requirements. The JTA transaction cycle can span multiple JDBC connection life cycles. Also for hibernate based on JTA transactions, the JTA transaction spans multiple sessions.

JTA transactions are maintained by JTA Container, and the life cycle of transactions is maintained by JTA container, regardless of the specific connection.

It is important to note that the connection involved in JTA transactions need to avoid interfering with transaction management. This means that if we use JTA Transaction, we should not call Hibernate's Transaction function again.

Copyright notice: I feel like I'm doing a good job. I hope you can move your mouse and keyboard for me to order a praise or give me a comment, under the Grateful!_____________________________________________________ __ Welcome reprint, in the hope that you reprint at the same time, add the original address, thank you with

Hibernate Transaction Management