[hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Steve Ebersole]

You confused me more :)

One the one had you say that we will use this fact of whether the
transaction has been disassociated to indicate whether the transaction is
completing normally (disassociated == true) or timed-out (disassociated ==
false).  But at the same time you are saying that it is quite possible that
we could still receive the afterCompletion callback in the timed-out case
and have (disassociated == true) due to race conditions.

So what is this buying us?


On Tue, Mar 10, 2015 at 11:09 AM, Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 03/10/2015 11:44 AM, Steve Ebersole wrote:
>
>> Scott, I am not following.  Pardon me if I am being dense :)
>>
>> Today, in our afterCompletion hooks we have code that, in the case of
>> rollback, tries to make a determination of whether the rollback is due
>> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
>> then we delay the afterCompletion processing.
>>
>
> Currently, in our afterCompletion hooks, the determining code isn't aware
> of the current/last application thread id.  I think that we are only
> tracking the first thread id that is used with the Hibernate session but
> not the last thread id.
>
>
>> So how, specifically, would this be different in what you propose?
>>
>
> The new approach will not use thread id, instead in our afterCompletion
> call, we will have the TM level knowledge, of whether the application
> thread has called tx rollback/suspend/commit yet.  If the application
> thread has called tx rollback/suspend/commit already, the afterCompletion
> call can safely clear managed entities from the session without violating
> concurrency concerns.  If the application has not yet called tx
> rollback/suspend/commit yet, we need to defer the clearing of the Hibernate
> session, until the TM listener calls us back, to let us know that the
> application has called tx rollback/suspend/commit, at which time we can
> safely clear the Hibernate session without violating (Hibernate session)
> concurrency concerns.
>
>
>> Are you saying that with this listener approach, that the listener would
>> be notified of disassociation prior to the afterCompletion callback on
>> our RegisteredSynchronization?  But in the timeout case, the
>> disassociation would happen later?
>>
>
> Yes.  It is also possible that in the timeout case, that the
> disassociation will come first (e.g. if there is a race between the app
> committing the transaction and the reaper thread timing out) but more
> likely that the disassociation comes later for the timeout case.
>
> FYI, the TM level SPI changes [4][5] are still open for review.
>
> Scott
>
> [4] https://github.com/jbosstm/jboss-transaction-spi/pull/5
> [5] https://github.com/jbosstm/narayana/pull/810
>
>
>> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>     With a proposed TM level listener, we will have an SPI for
>> notification
>>     of when application threads associated with a JTA transaction, become
>>     disassociated with the transaction (tm.commit/rollback/suspend time).
>>     Having this knowledge in a synchronization callback, can determine
>>     whether the persistence context should be cleared directly from the
>>     Synchronization.afterCompletion(int) call or should be deferred until
>>     the transaction is disassociated from the JTA transaction.
>>
>>     This idea is based on a TM level listener approach that Tom Jenkinson
>>     [1] suggested.  Mike Musgrove has a "proof of concept" implementation
>> of
>>     the suggested changes [2].  I did some testing with [3] to see if the
>>     improvement helps with clearing entities that might still be in the
>>     persistence context after a background tx timeout.
>>
>>     I'm wondering if in the Hibernate ORM
>>     Synchronization.afterCompletion(int status) implementation, in case
>> of
>>     tx rollback, if we could defer the clearing of the Hibernate session
>> to
>>     be handled by the JtaPlatform.  This could be setup at
>>     EntityManager.joinTransaction() time (if a new property like
>>     "hibernate.transaction.defer_clear_session" is true).  Perhaps via a
>>     JtaPlatform.joinTransaction(EntityManager) registration call?
>>
>>     Thoughts?
>>
>>     Scott
>>
>>     [1] https://developer.jboss.org/thread/252572?start=45&tstart=0
>>
>>     [2]
>>     https://github.com/mmusgrov/jboss-transaction-spi/blob/
>> threadDisassociationListener/src/main/java/org/jboss/tm/
>>
>>     [3]
>>     https://github.com/scottmarlow/wildfly/tree/
>> transactiontimeout_clientut_noejb_wildfly9_march5_2015
>>
>>     _______________________________________________
>>     hibernate-dev mailing list
>>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>