11:30 a.m.
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(a)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(a)redhat.com
> <mailto:smarlow@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>