[hibernate-dev] JdbcSession proposal

[Steve Ebersole]

I tend to agree...
On Dec 7, 2013 10:23 AM, "Scott Marlow" <smarlow at redhat.com> wrote:

> On 12/06/2013 04:45 PM, Scott Marlow wrote:
>
>> I think this is an excellent question, my preference is to fail-fast in
>> some fashion.
>>
>> JTA 1.1 spec description of Transaction.setRollbackOnly():
>>
>> "
>> public void setRollbackOnly() throws IllegalStateException,
>> SystemException
>>
>> Modify the transaction associated with the target object such that the
>> only possible outcome of the transaction is to roll back the transaction.
>> "
>>
>>   From an EJB point of view, the EJB container will eventually notice
>> that the transaction is marked for rollback only when the EJB bean
>> invocation completes but its not clear (to me) what this means at the
>> JPA level.
>>
>> Might be worth asking the JBossTS team, this question.
>>
>
> I believe that a future EE or JPA expert group will discuss whether
> applications can expect a transaction to fail-fast in the JPA persistence
> provider.  The discussion about this came up as part of a TCK issue
> (CTS-182 related whatever that is ;)
>
> I'm in favor of fail-fast as soon as possible, so that the application
> doesn't spend (potentially), hours before attempting to commit the JTA
> transaction, only to then realize that it is marked rollback only.  This
> doesn't seem that much different than detecting that the active JTA
> transaction has timed out.
>
>
>> On 12/06/2013 03:38 PM, Steve Ebersole wrote:
>>
>>> 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
>>>>>
>>>>>  _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>