More in-line below.
On 08/05/2014 10:52 AM, Scott Marlow wrote:
> Steve,
>
> This is the test case that I was talking about on IRC. It simulates
> what happens when several remote EJB calls occur using the same JTA
> transaction. This case is probably common enough that we should solve it.
>
> T
Steve,
This is the test case that I was talking about on IRC. It simulates
what happens when several remote EJB calls occur using the same JTA
transaction. This case is probably common enough that we should solve it.
The workaround is to set hibernate.jta.track_by_thread=false.
On 06/24/20
I pushed a test case that simulates what can happen with remote EJB
invocations that share the same JTA transaction & EntityManager. The
"Transaction was rolled back in a different thread!" error [2] is thrown
but shouldn't be, since the active application thread has changed to a
different thr
>
>> * Relying on the JTA Synchronization makes sense conceptually, but have we
>> received any feedback from JBossTS?
>
>> * Regarding the above, +1 for (conceptually) not caring about
>> Synchronization failing for rollback-only and failing fast. But, just want
>> to make sure we're not overl
Are there any specific parts that you would still like feedback on?
On 12/04/2013 12:27 PM, 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 concept
See inline...
P.S. Latest revs pushed to my upstream repo
On 01/06/2014 02:48 PM, Brett Meyer wrote:
> * +1 for the "Operation API", over the granular set of boilerplate code.
> Also, imo, I'd overload the API methods with the specific Operation impl
> arguments (ex: #accept(PreparedStatement
s just from a preliminary look -- I'll go through the code in more detail
when I can.
Brett Meyer
Red Hat, Hibernate ORM
- Original Message -
From: "Steve Ebersole"
To: "Scott Marlow"
Cc: "hibernate-dev"
Sent: Monday, December 9, 2013 2:00:38 PM
S
That would make it a JTA spec requirement.
>
> More feedback coming...
>
> - Original Message -
>
> From: "Steve Ebersole" <mailto:st...@hibernate.org>>
> To: "hi
chronization 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 fee
zation(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
I've kind of guessed what you mean in the ReadMe and
>> created https://gist.github.com/gbadner/7837050 . Feel free to ignore
>> this gist if you've already started fleshing this out.
>>
>> I'm not sure how the synchronizations all work for each case,
h case, but I imagine
> it will really help clean up the logic splitting up the cases (which is
> great!).
>
> Regards,
> Gail
>
> ----- Original Message -
>> From: "Steve Ebersole"
>> To: "Gail Badner"
>> Cc: "Sanne Grinovero&q
up the logic splitting up the cases (which is great!).
Regards,
Gail
- Original Message -
> From: "Steve Ebersole"
> To: "Gail Badner"
> Cc: "Sanne Grinovero" , "hibernate-dev"
> , "Tom Jenkinson"
> , "Scott Marlow&qu
On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:
>
> It would be nice to make the return value generic:
>
> public T accept(PreparedStatementQueryOperation operation, Class
> resultClass);
95 times out of 100 inside Hibernate code we really can't take advantage
of the parameterized type.
;
> > >> 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:
> > >&g
e that the transaction
> has been marked for rollback only.
> >>>
> >>> That would make it a JTA spec requirement.
> >>>
> >>> More feedback coming...
> >>>
> >>> - Original Message -
> >>>> From: &qu
>>> That would make it a JTA spec requirement.
>>>
>>> More feedback coming...
>>>
>>> - Original Message -
>>>> From: "Steve Ebersole"
>>>> To: "hibernate-dev"
>>>> Sent: Friday, Decemb
marked for rollback only.
>>
>> That would make it a JTA spec requirement.
>>
>> More feedback coming...
>>
>> - Original Message -
>>> From: "Steve Ebersole"
>>> To: "hibernate-dev"
>>> Sent: Friday, Decem
t; From: "Steve Ebersole"
>> To: "hibernate-dev"
>> 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
...
- Original Message -
> From: "Steve Ebersole"
> To: "hibernate-dev"
> 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
&g
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 poten
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
inp
22 matches
Mail list logo
