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 <smar...@redhat.com > <mailto:smar...@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 <smar...@redhat.com > <mailto:smar...@redhat.com> > <mailto:smar...@redhat.com <mailto:smar...@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@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > <mailto:hibernate-dev@lists.__jboss.org > <mailto:hibernate-dev@lists.jboss.org>> > https://lists.jboss.org/__mailman/listinfo/hibernate-dev > <https://lists.jboss.org/mailman/listinfo/hibernate-dev> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
