[hibernate-dev] JdbcSession proposal

[Sanne Grinovero]

I'm wondering if someone might want to define such a
PreparedStatementQueryOperation just for reading data.

In such case, could there be any benefit in setting #setRollbackOnly() ?
I'm not just thinking of being paranoid to "protect" the data from
side-effects but also it could imply that the TransactionManager could
apply some optimisations?

Sanne


On 6 December 2013 21:45, Scott Marlow <smarlow at redhat.com> 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.
>
> 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