Hibernate Transaction Management

Before explaining things Management in hibernate, we must first understand some basic concepts to help us understand why things management should be used, what are its basic features or restrictions,
 
So the first thing we should know is the four basic features of things, which we often call ACID [atomicity, consistency, isolation, durability ];
 
Second, we should know that the isolation level of things, that is, through a mechanism, separates multiple things that run concurrently to ensure their independence during execution. It is generally divided into four isolation levels: Read Uncommitted, Read Committed, Repeatable Read, and Serializable. The degree of closeness of these four isolation levels increases one by one, and the performance of colleagues decreases in turn, when dirty reads, unrepeatable reads, and virtual reads, the three databases may have vulnerabilities, the four levels of countermeasures are different, that is, in these four isolation levels, the three possible situations are: 1. it may be dirty read, maybe re-reading, or maybe virtual read; 2. it cannot be dirty read, it may be re-read, or it may be virtual read; 3. it cannot be dirty read, it cannot be re-read, it may be virtual read 4. none of the three vulnerabilities can occur. Therefore, during daily use, you need to choose based on the actual situation to maintain the optimal balance of the system.
 
Hibernate is a lightweight encapsulation of jdbc and does not have the ability to manage transactions. At the transaction management layer, it is generally delegated to the underlying jdbc and jta for scheduling. The default transaction processing mechanism is based on jdbc transaction. Of course, we can also implement it by configuring jta:
 
Xml Code
<Hibernate-configuration>
<Session-factory>
........
<Property name = "hibernate. transaction. factory_class">
Net. sf. hibernate. transaction. JTATransactionFactory // JTA
<! -- Net. sf. hibernate. transaction. JDBCTransactionFactory --> // JDBC
</Property>
........
</Sesssion-factoty>
</Hibernate-configuration>
 
Entrusting a transaction to jdbc is undoubtedly the easiest way. hibernate supports it as the default method, and its encapsulation is also very simple. For example, when we are processing this Code:
 
Java code
Session = sessionFactory. openSession ();
Transaction tx = session. beginTransaction ();
......
Tx. commit ();
 
In terms of jdbc, what we actually do is:
 
Java code
Connection dbconn = getConnection ();
Dbconn. setAutoCommit (false );
......
Dbconn. commit ();
 
This is so simple. In other words, the hibernate submission method is submitted with the native jdbc at the underlying layer. Note that during openSession, the AutoCommit attribute of the underlying jdbc has been disabled. Unless the jdbc connection goes to commit, the operations executed will not produce any effect on the database. Here, we need to display and execute tx. commit () [Except for non-transactional databases, such as Mysql ISam]
 
The biggest difference between JTA and jdbc is that JTA provides cross-session transaction management capabilities. A jdbc transaction is managed by a Connection, and its lifecycle is limited to that of a Connection. JTA is implemented by the JTA container. The container can schedule many current connections, so it can span multiple Connection lifecycles, and thus provide cross-session capabilities.
 
For example, the following code is completely correct under jdbc, but problems may occur in jta:
 
Java code
Class ClassA {
Public void save (User user ){
Session session = sessionFactory. openSession ();
Transaction tx = session. beginTransaction ();
Session. save (user );
Tx. commit ();

Session. close ();
}
}
Java code
<Pre class = "java" name = "code"> class ClassB {
Public void save (Order order ){
Session session = sessionFactory. openSession ();
Transaction tx = session. beginTransaction ();
Session. save (order );
Tx. commit ();

Session. close ();
}
} </Pre>
Class ClassC {
Public void save (){
.....
UserTransaction tx = (UserTranscation) (new InitialContext (). lookup ("...."));
ClassA. save (user );
Java code
ClassB. save (oreder );
Tx. commit ();

......
}
}
The problem here is that ClassA and B call the Transaction function of hibernate. In the JTA package of hibernate, Session. beginTransaction also executes InitialContext. lookup to get the instance of UserTransaction, but in tx. in commit, both ClassA and B attempt to declare their own things, resulting in errors, because we know that jdbc things cannot be cross-connection or cross-session. If jta is used, we can modify the above Code to implement the operation:
Java code
Class ClassA {
Public void save (User user ){
Session session = sessionFactory. openSession ();
Session. save (user );
Session. close ();
}
}
 
Class ClassB {
Public void save (Order order ){
Session session = sessionFactory. openSession ();
Session. save (order );

Session. close ();
}
}
 
Class ClassC {
Public void save (){
.....
Session session = sessionFactory. openSession ();
Transaction tx = session. beginTransaction ();
ClassA. save (user );
ClassB. save (order );
Tx. commit ();

Session. close ();
}
}
 
Using JTA Transaction in EJB is undoubtedly the easiest. We only need to declare the attribute of the save method as Required, and the Ejb container will automatically maintain and execute the things in the process. Www.2cto.com