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:
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