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
the next stage with some actual interfaces, impls and usages to help
illustrate some of the proposed concepts.
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 :)