The bigger question is whether we care. Is there really a benefit to continuing work when a transaction is marked for rollback only?
On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote: > Hi Steve, > > Looking at the Javadoc for > javax.transaction.Transaction.registerSynchronization(Synchronization sync), > I see: > > Throws: RollbackException - Thrown to indicate that the transaction has been > marked for rollback only. > > That would make it a JTA spec requirement. > > More feedback coming... > > ----- Original Message ----- >> From: "Steve Ebersole" <st...@hibernate.org> >> To: "hibernate-dev" <hibernate-dev@lists.jboss.org> >> Sent: Friday, December 6, 2013 10:07:22 AM >> Subject: Re: [hibernate-dev] JdbcSession proposal >> >> So I'll get the ball rolling :) Here is one thing in particular I was >> hoping to start a discussion on... >> >> For JTA transactions we currently have a lot of complex logic to manage >> who "drives" the transaction flow into Hibernate (in terms of Hibernate >> reacting to the completion). There are potentially 2 drivers: >> 1) A JTA Synchronization registered with the JTA system >> 2) The org.hibernate.Transaction instance >> >> A lot of the complexity in our current code comes from the fact that we >> have a lot of attempting to handle cases in which the JTA >> Synchronization cannot be registered. So one of the simplifications I >> am wanting to make here is to say that the driver will always be the >> JTA Synchronization. So I am trying to determine how "actual" these >> cases where the "JTA Synchronization cannot be registered" are. >> >> The only one that I am aware of IIRC is that JTA Synchronization cannot >> be registered on transactions that are marked for rollback-only. I >> cannot remember though if that was a specific provider (JBossTS?) or a >> JTA/JTS spec requirement. >> >> So the proposal I have is that for JTA cases we always register the JTA >> Synchronization and allow that to drive the "before/after completion" >> callbacks (the org.hibernate.Transaction would still potentially manage >> actually calling commit/rollback on the >> TransactionManager/UserTransaction). In short, does any one see >> problems with this approach? >> >> >> On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote: >>> I found a few spare minutes to work on this a little and move it into >>> the next stage with some actual interfaces, impls and usages to help >>> illustrate some of the proposed concepts. >>> >>> https://github.com/sebersole/JdbcSession >>> >>> The README.md is very up-to-date and detailed. Would be good to get >>> input from others. >>> >>> >>> P.S. I probably dislike the *Inflow naming more than you do :) >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
