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
That would make it a JTA spec requirement.
More feedback coming...
----- Original Message -----
From: "Steve Ebersole" <steve(a)hibernate.org>
To: "hibernate-dev" <hibernate-dev(a)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.
> 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