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.

So how, specifically, would this be different in what you propose?

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?

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/threadDisassociati... [3] https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_n... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <mailto:smarlow@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(a)redhat.com <mailto:smarlow@redhat.com> <mailto:smarlow@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 <https://developer.jboss.org/thread/252572?start=45&tstart=0> [2] https://github.com/mmusgrov/__jboss-transaction-spi/blob/__threadDisassoc... <https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociati... [3] https://github.com/__scottmarlow/wildfly/tree/__transactiontimeout_client... <https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_n... _________________________________________________ hibernate-dev mailing list hibernate-dev(a)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>

> > So what is this buying us? > The current Hibernate ORM thread id checking, does not properly handle the case when the application thread changes between calls to the Hibernate session. The new approach does handle the application thread changing between session invocations and also covers a few other cases as well (like clearing the persistence context after the application may of added another entity after the background thread rolled back the transaction). _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Yeah, which is great when you can rely on impl-specific apis.

I'll consider this, but its not super high on my priority list. I guess we could implement some kind of way for the JtaPlatform to indicate the "type of timeout tracking" to do and develop a new NarayanaJtaPltaform that does this.

On Fri, Aug 7, 2015 at 11:30 AM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: https://github.com/wildfly/wildfly/pull/7909 uses the Narayana org.jboss.tm.listener.TransactionListenerRegistry to be notified when the transaction is associated/deassociated with the JTA transaction. I think that Hibernate ORM could do something similar with the org.jboss.tm.listener.TransactionListenerRegistry to protect against clearing the persistence context from a non-application thread, while the application thread may be actively using the persistence context. I think this approach is simpler than the thread id tracking. On 03/10/2015 01:51 PM, Scott Marlow wrote: >> >> So what is this buying us? >> > > The current Hibernate ORM thread id checking, does not properly handle > the case when the application thread changes between calls to the > Hibernate session. The new approach does handle the application thread > changing between session invocations and also covers a few other cases > as well (like clearing the persistence context after the application may > of added another entity after the background thread rolled back the > transaction). > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >