RE: [Hibernate-devel] Simple transaction management

[Gavin_King/Cirrus%<CI...@ci...>]

> forgive me if this a brain dead question - i am just skimming all this
> because i currently don't have the time right now to do it justice -
> what is the general structure of code that would now be used in a CMT
> environment?  i was just concerned that a commit is going to replace the
> flush, which doesn't make sense (in this environment).


For a CMTTransaction or JTATransaction Transaction.commit() would call
Session.flush().
For a JDBCTransaction Transaction.commit() would call Session.flush() then
Session.connection().commit().

The call to flush() is just an extra convenience. Essentially
Transaction.commit() has empty implementations for container managed
transactions and a non-empty implementation for JDBC transactions....

Brad, I don't see any other sensible approach to this. If we want to
abstract the underlying transaction mechanism, as agrued by Anton, there
has to be a method which indicates conclusion of the unit of work (because
JDBCTransaction needs to call commit() from there). There also needs to be
a method which forces rollback ( whether it calls rollback() or
setRollbackOnly() ). If you really object to the first method being called
commit(), what else should we call it?

I guess if you really despise this, you can continue using the current
approach. I am not proposing ANY change at all to existing code.

Otherwise suggest a better alternative....

Gavin