Hibernate is a lightweight object package for JDBC. Hibernate itself does not have Transaction processing. Hibernate's Transaction is actually encapsulation of the underlying JDBC Transaction, or the package of JTA Transaction, the following detailed analysis: Hibernate can be configured as JDBCTransaction or JTATransaction, depending on your configuration hibernate.properties in: quote: # hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory # hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory If you don't configure anything, use JDBCTransaction by default if you are configured: hibernate.Transaction.Factory_class net.sf.hibernate.Transaction.jtatransactionFactory will use JTATRRANSACTION Whether you are ready to let Hibernate use JDBCTRANSACTION, or JTATRRANSACTION, my advice is to do nothing with, it will keep the default state, as follows: quote: # hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory # hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory below I will give the reason in the analysis. I. JDBC Transaction See when using JDBC Transaction: Code: Session session = sf.opensession (); transaction tx = session.begintransactioin (); ... session.flush (); tx.commit () Session.close (); this is the default situation, when you use Hibernate in your code, it is actually JDBCTRANSACTION.
So what is JDBCTRANSACTION? Take a look at the source code: hibernate2.0.3 Source code class code: Net.sf.hibernate.Transaction.jdbctransaction: public void begin () throws hibernateException {log.debug ("begin"); try {Toggleautocommit = Session.connection (). getAutoCommit () session.connection () session.Connection (); setOutocommit (false);} catch (sqlexception e) {log.error ("Begin Failed", E); throw new TransactionException ("Begin Failed with SQL Exception: ", e);} Begun = true;} This is the method of launching Transaction, see Connection (). SETAUTOCOMMIT (FALSE)? Is it very familiar? Look at the code: public void commit () throws HibernateException {if throw new TransactionException ( "Transaction not successfully started"); log.debug ( "commit"); try {if (session.getFlushMode () = FlushMode (begun!)! .Never) ("commch (" commitness) {log.rror ("commit failed, e) {log.error (" commit failed, e) {log.error ("commit failed"; throw new transactionException Failed with SQL Exception: ", e);}} finally {session.AFTERTRANSACTIONCOMPLET ();} Toggleautocommit ();} This is the submission method and see connect (). commit ()? You don't have to say more, this class code is very easy to understand. What do you understand? I now translate the example written by hibernate into JDBC, everyone is a bit: Code: Connection conn = ...; <- session = sf.opensession (); conn.setautocommit (false); <--- TX = session.begintransactioin (); ... <--- ... conn.commit (); <- tx.commit (); (corresponding to the two sentences) Conn.Setautocommit (TRUE); conn.close (); <--- session.close (); understand, Hibernate's JDBCTransaction is CONN.Commit, there is no mystery, but in hibernate, Session is open, it will automatically automatically CONN .Setautocommit (False), unlike average JDBC,
The default is True, so you don't have the relationship without writing commit, because Hibernate has turned off the autocommit, so when you use Hibernate, you don't respond at all in the program. Second, JTATRRANSACTION If you use Hibernate in EJB, or prepare to manage cross session's long transactions, then you need to use JTATRRRANSACTION, first look at an example: Code: 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 the standard use JTA code snippet, which is cross session, its lifecycle is longer than Session. If you use hibernate in EJB, it is the easiest, you don't write any transaction code, you can use a certain method to use a transaction directly on the EJB deployment descriptor. Now let's analyze the source code of JTATRRRRRANSACTION, net.sf.hibernate.transaction.jtatransaction: Code: public void begin (InitialContext Context, ... UT = (useertionAction) context.lookup (utName); ... Is it clear? And the code I wrote above TX = new initialContext (). Lookup ("javax.transaction.usertransaction); Is it exactly the same? Code: public void commit () ... if (NEWTRANSACTION Ut.commit (); ... JTATRRANSACTION control is slightly complicated, but you can still see how Hibernate is encapsulated by JTA's Transaction code. But have you seen something? Take a closer, hibernate transaction is From the session, tx = session.begintransaction (), finally submit TX, then session.close, which is fully compliant with the sequence of operation of JDBC Transaction, but this order is completely contradictory with JTA's TransactioIn operation! !! JTA is first launched first, then launch session, shut down Session, finally submit transaction, so do you want to use Hibernate's Transaction, but should be like the JTA's code snippet That is used. Summary: 1. Use hibernate on JDBC to write Hibernate Transaction code, otherwise the database has no response.
At this time, Hibernate is already Connection.commit. It is 2. Use Hibernate to write JTA transaction code on JTA, do not write hibernate's Transaction code, otherwise the program will report an error 3, use hibernate on EJB, don't write, in EJB Deployment descriptor inside configuration code: | --- CMT (Container Managed Transaction) | | --- JDBC Transaction | | ---- JTA Transaction Robbin: You said Hibernate's JDBCTRANSACTION is Conn.commit, which is not mysterious, only in Hibernate, when session opens, automatically conn.setautocommit (false), unlike average JDBC, the default is True, so You don't have the relationship without writing commit, because Hibernate has turned off the autocommit, so when you use Hibernate, you don't write Transaction in the program, the database does not respond at all, "but sf.opengsession (), no SetAutocommit (false), I want to ask, if you don't write any transaction code, such as: code: session s = sf.opensession (); ... S.Close (); database will not react ( At this point, it should be the default autonommit to true). Also, I want to ask: 1. S.Flush () is a must be required 2. S.Close () is not to turn off, for example, you mentioned above: Code: javax.transaction.usertransaction tx = new initialContext () .lookup ("javax.transaction.usertransaction); session s1 = sf.opensession (); ... s1.flush (); s1.close (); ... session s2 = sf.opensession (); .. S2.Clush (); tx.commit (); S1 does not close, using S1 in code to operate using S2 can not (I think this more saves resources, do not need repeated connection, close) Quote: But sf.opengsession (), there is no setAutocommit (false), I want to ask, if you do not write any transaction code, such as: session s = sf.opensession (); ... S.Close (); The database will not react (which should be the default autonommit to TRUE). Will not react. When SF.OpenSession () creates a session instance, conn.setautocommit (FALSE) has been called. Quote: In addition, I want to ask: 1. S.flush () is a must-have to turn off s.flush is not necessary, s.close () will call once s.flush () s.close () should be turned off under normal circumstances unless you are using Threadlocal management session.
