[hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...
Scott Marlow
smarlow at redhat.com
Tue Mar 10 13:42:42 EDT 2015
On 03/10/2015 12:30 PM, Steve Ebersole wrote:
> 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.
When we have both disassociated == true and afterCompletion has been
called, then it is safe to clear the Hibernate session. The order that
these conditions are detected, does not matter.
>
> So what is this buying us?
>
>
> On Tue, Mar 10, 2015 at 11:09 AM, Scott Marlow <smarlow at redhat.com
> <mailto: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
> <https://github.com/jbosstm/jboss-transaction-spi/pull/5>
> [5] https://github.com/jbosstm/__narayana/pull/810
> <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>
> <mailto: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
> <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/
> <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
> <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>
> <mailto:hibernate-dev at lists.__jboss.org
> <mailto:hibernate-dev at lists.jboss.org>>
> https://lists.jboss.org/__mailman/listinfo/hibernate-dev
> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>
>
More information about the hibernate-dev
mailing list