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
