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 <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 > [5] 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>> 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@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> 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
