don't get me wrong, i don't despise this change at all. :-) i just remember when i was first using hibernate, i got it going in a stanalone application. i then tried using it in a CMT environment, which was a little frustrating because back then u still had to call commit, which certainly isn't intuitive.
however, all is ok, as the flush method is staying on session. we simply need a code example in the docs showing the general code structure in different environments (which i don't mind helping out on). brad > -----Original Message----- > From: Gavin_King/[EMAIL PROTECTED] > [mailto:Gavin_King/[EMAIL PROTECTED] > Sent: Tuesday, 21 May 2002 5:17 PM > To: [EMAIL PROTECTED] > Subject: RE: [Hibernate-devel] Simple transaction management > > > > > 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 > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Hibernate-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
