Analysis of hibernate jtatransaction and jdbctransation

Hibernate is a lightweight object encapsulation of JDBC. hibernate itself does not have the transaction processing function. hibernate's transaction is actually the encapsulation of the underlying JDBC transaction, or the encapsulation of JTA transaction, the following is a detailed analysis:
　　
Hibernate can be configured as jdbctransaction or jtatransaction, depending on your configuration in hibernate. properties:
　　
# Hibernate. transaction. factory_class
Net. SF. hibernate. transaction. jtatransactionfactory
# Hibernate. transaction. factory_class
Net. SF. hibernate. transaction. jdbctransactionfactory
　　
If you do not configure anything, jdbctransaction is used by default. If you configure it:
　　
Hibernate. transaction. factory_class
Net. SF. hibernate. transaction. jtatransactionfactory
　　
Jtatransaction will be used. No matter whether you want hibernate to use jdbctransaction or jtatransaction, my advice is to keep it in the default state, as shown below:
　　
# Hibernate. transaction. factory_class
Net. SF. hibernate. transaction. jtatransactionfactory
# Hibernate. transaction. factory_class
Net. SF. hibernate. transaction. jdbctransactionfactory
　　
In the following analysis, I will give the reason.
　　
　　I. JDBC transaction
　　
Let's take a look at our code example when using JDBC transaction:
　　
Session session = SF. opensession ();
Transaction Tx = session. begintransactioin ();
...
Session. Flush ();
TX. Commit ();
Session. Close ();
　　
This is the default situation. When you use hibernate transaction in code, it is actually jdbctransaction. So what exactly is jdbctransaction? Let's take a look at the source code:
　　
Class in source code of hibernate2.0.3
　　
Net. SF. hibernate. transaction. jdbctransaction:
　　
Public void begin () throws hibernateexception {
...
If (toggleautocommit) Session. Connection (). setautocommit (false );
...
}
　　
This is the method for starting transaction. Do you see connection (). setautocommit (false? Are you familiar with this?
　　
Let's take a look.
　　
Public void commit () throws hibernateexception {
...
Try {
If (session. getflushmode ()! = Flushmode. Never) Session. Flush ();
Try {
Session. Connection (). Commit ();
Committed = true;
}
...
Toggleautocommit ();
}
　　
This is the submission method. Have you seen connection (). Commit? I don't need to talk about the following. This class of code is very simple and easy to understand. Through reading, we can understand what hibernate's transaction is doing? Now I have translated the example written in hibernate into JDBC, and you can see it at a Glance:
　　
Connection conn =...; <--- session = SF. opensession ();
Conn. setautocommit (false); <--- Tx = session. begintransactioin ();
... <---...
Conn. Commit (); <--- Tx. Commit (); (two sentences on the left)
Conn. setautocommit (true );
Conn. Close (); <--- session. Close ();
　　
See it. hibernate's jdbctransaction is essentially Conn. there is no mystery at all, but in hibernate, when the session is opened, it will automatically Conn. setautocommit (false). Unlike JDBC, the default value is true. Therefore, it does not matter if you do not write a commit statement. Because hibernate has disabled autocommit, when you use hibernate, if you do not write transaction in the program, the database will not respond at all.
　　
　　Ii. jtatransaction
　　
If you use hibernate in EJB, or you want to use JTA to manage long transactions across sessions, you need to use jtatransaction. Let's look at an example:
　　
Javax. transaction. usertransaction Tx = new
Initialcontext (). Lookup ("javax. transaction. usertransaction ");
Session S1 = SF. opensession ();
...
S1.flush ();
S1.close ();
...
Session S2 = SF. opensession ();
...
S2.flush ();
S2.close ();
TX. Commit ();
　　
This is a standard piece of code using JTA. transaction is cross-session, and its lifecycle is longer than session. If you use hibernate in EJB, It is the simplest. You should not write any transaction code, you can directly configure the transaction usage of the XX method on the EJB deployment descriptor.
　　
Now let's analyze the source code of jtatransaction, net. SF. hibernate. transaction. jtatransaction:
　　
Public void begin (initialcontext context ,...
...
Ut = (usertransaction) Context. Lookup (utname );
...
　　
Are you clear? And the code I wrote above Tx = new initial context? (). Lookup ("javax. transaction. usertransaction"); is it the same?
　　
Public void commit ()...
...
If (newtransaction) ut. Commit ();
...
　　
The control of jtatransaction is a little complicated, but it can still be clearly seen how hibernate encapsulates JTA's transaction code.
　　
But have you seen any problems? Think about it, Hibernate transaction is obtained from the session, Tx = session. begintransaction (), submit TX first, and then session. close, which fully complies with the Operation Sequence of the JDBC transaction, but this sequence is totally different from the transactioin Operation Sequence of JTA !!! JTA starts transaction first, then starts the session, closes the session, and finally submits the transaction. Therefore, when you use the transaction of JTA, never use the transaction of hibernate, it should be used like the JTA code snippet above.
　　
　　Summary:
　　
1. To use hibernate on JDBC, you must write the hibernate transaction code; otherwise, the database will not respond. In this case, the transaction of Hibernate is connection. Commit.
　　
2. Use hibernate on JTA to write the transaction code of JTA. Do not write the transaction code of hibernate. Otherwise, the program reports an error.
　　
3. Do not write any transactioin code using hibernate on EJB. configure it in the EJB deployment descriptor.
　　
| --- CMT (container managed transaction)
|
| --- BMT (bean managed transaction)
|
| ---- JDBC transaction
|
| ---- JTA transaction