Well, let's focus on non-JTA env, i.e. using JDBCTransactionFactory. Still, the question remains: what is that JDBCTransaction's mapping to underlying DB transaction (as viewed by MySQL server).
Here's the reason for my question:
-MySQL 5.0 server defaults to autocommit after every SQL statement, and apparently, disabling that complicates (or makes impossible) DB clustering.
-Hibernate, on the other hand, defaults to false for property hibernate.connection.autocommit (and enabling this is "not recommended").
So, now let's say we have the following code:
Code:
try{
Session s = sf.openSession();
s.beginTransaction();
s.save(A);
s.save(B);
s.getTransaction().commit();
}
catch(RuntimeException ex){
s.getTransaction.rollback();
}
Let's say insert of B is rejected by DB. Application logic would expect both inserts (of A, and B) to be rolled back since hibernate.connection.autocommit == false. However, since MySQL server's default setting is autocommit==true (commit after each statement), 'insert A' will NOT be rolled back by DB. Unless Hibernate settings somehow override db server settings at runtime....
Hence my original question. I suppose it can be asked another way:
Does setting hibernate.connection.autocommit == false guarantee that
underlying db's autocommit setting is also now false?
Login
FAQ
Search
