Doesn't appear as this got through. Trying again... N
-----Original Message----- From: Neill Robbins Sent: 16 October 2003 09:36 To: '[EMAIL PROTECTED]' Subject: Hibernate issue found on [Springframework-developer] - Hibernate commit/rollback Importance: Low Sirs, I noticed this post on the Spring developer ist. It seemed important enough to make you guys aware of... Regards, N -----Original Message----- From: jürgen höller [werk3AT] [mailto:[EMAIL PROTECTED] Sent: 16 October 2003 05:53 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Springframework-developer] Hibernate commit/rollback Importance: Low You're right, of course, but there's a general issue. I've checked the implementation of Hibernate's JDBCTransaction: It really behaves the way I've outlined, i.e. if there's a flushing failure on commit, the commit call returns without having rolled back the database transaction. We need to make sure that the database transaction is completed, i.e. either committed or rolled back, after the transaction manager has finished its work. Juergen -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Do 16.10.2003 02:34 An: jürgen höller [werk3AT] Cc: [EMAIL PROTECTED] Betreff: Re: [Springframework-developer] Hibernate commit/rollback Juergen, The log shows that it is a MySQL database - do we know that the table is one that support transactions? If not then no matter what we or hibernate do is going to help. Thomas > There's a bug entry on SourceForge regarding HibernateTransactionManager's > committing: > > If the flushing of changes is delayed (i.e. HibernateTemplate is in > FLUSH_AUTO mode, not in FLUSH_EAGER), the Hibernate commit call will first > implictly cause a flush. The problem is that that flush might throw an > exception which causes Hibernate's commit implementation to return with the > exception, without a commit but unfortunately also without a rollback. > > The current implementation of HibernateTransactionManager will not cause an > explicit rollback in that case, as it assumes that the commit has failed and > caused an implicit rollback. It takes that assumption from JTA: After a > failed commit, you don't have to invoke rollback anymore; the failed commit > has already completed the transaction with a rollback. > > If I understand correctly, a JDBC driver should behave the same: If a commit > has failed, rollback does not have to be invoked anymore. Would it actually > hurt if one still invoked rollback? Would that get ignored with most drivers, > or would it cause yet another exception, a la "transaction is already rolled > back" or "no transaction anymore"? > > I intend to fix the Hibernate transaction issue like this: First invoke flush > manually and treat it like data access, i.e. just commit if it succeeded, > else cause an explicit rollback. Aren't the semantics of Hibernate's commit > method a bit odd? Shouldn't it cause a rollback itself if the flush failed? > > I'm not sure about JDO in that respect. It will also flush changes at commit, > and there is no chance to cause an explicit flush before. The spec and the > javadocs are unclear about whether a flushing failure causes a rollback of > the datastore transaction, but I assume so. At least, it seems that rollback > can and should not be invoked after an exception on commit. > > Has anyone practical experience with these issues? > > Juergen > > > > > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
