[hibernate-dev] JdbcSession proposal

[Steve Ebersole]

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" <steve at hibernate.org>
>> To: "hibernate-dev" <hibernate-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>