RE: [Springframework-developer] Hibernate commit/rollback

[<tri...@tr...>]

Juergen,

A lot of the JDBC behavior seems to be implementation dependent - especially
more tricky situations.

I just found this in Oracle9i JDBC Developer’s Guide and Reference

Important:
 
 If auto-commit mode is disabled and you close the connection
   without explicitly committing or rolling back your last changes,
   then an implicit COMMIT operation is executed.

That's the opposite behavior from what I read in a JDBC book this morning - who
do you trust??  I'm going to try this when I get some time.

> 
> Of course, in the case of a flushing failure a rollback call makes sense. But
> what if the Connection.commit call fails? Does it add any value to
> additionally invoke rollback then?
> 

I would be surprised if a rollback call was necessary after a commit failed for
any database or driver implementation - but you never know and if you call
rollback inside it's own try/catch block then you can always ignore any
exceptions thrown during rollback.

Here is basically our question answered by someone at SAP (don't now if this
applies to all driver implementations):

-----
http://listserv.sap.com/pipermail/sapdb.general/2002-June/006822.html
Raimund Jacob wrote:

> 
> this is a JDBC question but i suspect that other client 
> libraries have 
> the same problem.
> 
> when i commit() a transaction in jdbc i consider my data safe 
> when the 
> method returns. but what if this method throws an SQLException (a 
> multi-purpse exception you usually just pass to the user) ?
> 
> is the transaction rolled back automatically ? do i have to do that ? 
> what if rollback() throws an exception ?
> 
> i cannot find a hint in the JDBC API doc nor in in the JDBC 
> spec. what 
> am i supposed to do when commit() fails ?

If an error was found in the kernel during commit, it is one of a number
of severe errors, the user should not work with the database any longer.
Therefore an implicit rollback release is done besides sending the found
error back to the application.
This is done no matter which kind of application is on top of the kernel.

Elke
SAP Labs Berlin
-----



This is from J2EE Developer's Guide - Transactions:

-----
 JDBC Transactions
A JDBC transaction is controlled by the transaction manager of the DBMS. You may
want to use JDBC transactions when wrapping legacy code inside a session bean.
To code a JDBC transaction, you invoke the commit and rollback methods of the
javax.sql.Connection interface. The beginning of a transaction is implicit. A
transaction begins with the first SQL statement that follows the most recent
commit, rollback, or connect statement. (This rule is generally true, but may
vary with DBMS vendor.)

The following code is from the WarehouseEJBexample, a session bean that uses the
Connection interface's methods to delimit bean-managed transactions. The ship
method starts by invoking setAutoCommit on the Connection object con. This
invocation tells the DBMS not to automatically commit every SQL statement. Next,
the ship method calls routines that update the order_item and inventory database
tables. If the updates succeed, the transaction is committed. But if an
exception is thrown, the transaction is rolled back.

public void ship (String productId, String orderId, int quantity) {

   try {
      con.setAutoCommit(false);
      updateOrderItem(productId, orderId);
      updateInventory(productId, quantity);
      con.commit();
   } catch (Exception ex) {
       try {
          con.rollback();
          throw new EJBException("Transaction failed: " +
             ex.getMessage());
       } catch (SQLException sqx) {
           throw new EJBException("Rollback failed: " +
              sqx.getMessage());
       }
   }
} 
-----
  

Thomas