On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: Hi, I'm trying to perform a specific action upon transaction rollback. Assuming this could be done using a custom javax.transaction.Synchronization, I tried to register a synchronization as follows: TransactionImplementor transaction = ...; // e.g. a CMTTransaction transaction.registerSynchronization( new MySync() ); And indeed beforeCompletion() is invoked as expected. But afterCompletion() never is. I debugged this a bit on WildFly and observed the following: * Hibernate ORM registers RegisteredSynchronization with JTA. RegisteredSynchronization manages (indirectly, through TransactionCoordinator, SynchronizationRegistry etc.) those synchronizations added through o.h.t.Transaction.registerSynchronization() * WildFly (specifically, TransactionUtil [1]) registers its own SessionSynchronization for closing the entity manager/session Now that second synchronization is called first, closing the session. Upon SessionImpl#close(), the SynchronizationRegistry is cleared. Then when afterComplection() is called on RegisteredSynchronization afterwards, any previously registered delegate synchronizations are gone already and thus do not get invoked. I believe I found a workaround for my case by registering my synchronization through JtaPlatform#registerSynchronization() (which registers it with the actual JTA transaction). My questions are: * Is this behaviour expected? * Is the work-around of doing the registration via JtaPlatform viable or are there any drawbacks which I'm not aware of? Thanks, --Gunnar [1] https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I just saw the below email response after I sent the last one. Sorry about that, will respond here also. :) On 03/10/2015 09:14 AM, Emmanuel Bernard wrote: > Ah synchronization ordering, it never gets old :) Steve might remember better but I don’t think we ever managed to convice the tx team to offer guaranteed ordering. We started discussing synchronization ordering as well (within the interposed group) and there is a WildFly specific code change being worked on to always run the JCA sync last (so IronJacamar can delist a resource that would of otherwise been leaked). > > Your workaround seems fine (if there is a JtaPlaform) but when we add more logic to your onRollback calls, we might want to offer access tot he Session to try compensating for example. In which case, we would be in trouble with the closed session. I don’t have a good idea. Hmm, for the new SPI that deals with registering "concurrency safe" OnRollback calls, I wonder if we should have an ordering priority, so that the session clear/OGM operations list presentation, can always run before the JPA container closes the session. In a discussion about changing the TM level Sync ordering for an unknown set of Syncs, we talked about specifying an ordering priority for registered Syncs, that idea will probably be useful for ordering the OnRollback calls if we enable that. > > I am a bit surprised WildFly closes the session but that might be per spec that the container manages these calls. Yes, only for a transaction scoped entity manager, do we have to close the session after the transaction ends. We don't do this for application managed (application needs to call EM.close()). For extended persistence contexts, we close the session, after the last referencing stateful bean is destroyed (tracking is done in the JPA container). Scott > >> On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> Hi, >> >> I'm trying to perform a specific action upon transaction rollback. >> >> Assuming this could be done using a custom >> javax.transaction.Synchronization, I tried to register a synchronization as >> follows: >> >> TransactionImplementor transaction = ...; // e.g. a CMTTransaction >> transaction.registerSynchronization( new MySync() ); >> >> And indeed beforeCompletion() is invoked as expected. But afterCompletion() >> never is. I debugged this a bit on WildFly and observed the following: >> >> * Hibernate ORM registers RegisteredSynchronization with JTA. >> RegisteredSynchronization manages (indirectly, through >> TransactionCoordinator, SynchronizationRegistry etc.) those >> synchronizations added through o.h.t.Transaction.registerSynchronization() >> * WildFly (specifically, TransactionUtil [1]) registers its own >> SessionSynchronization >> for closing the entity manager/session >> >> Now that second synchronization is called first, closing the session. Upon >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when >> afterComplection() is called on RegisteredSynchronization afterwards, any >> previously registered delegate synchronizations are gone already and thus >> do not get invoked. >> >> I believe I found a workaround for my case by registering my >> synchronization through JtaPlatform#registerSynchronization() (which >> registers it with the actual JTA transaction). >> >> My questions are: >> >> * Is this behaviour expected? >> * Is the work-around of doing the registration via JtaPlatform viable or >> are there any drawbacks which I'm not aware of? >> >> Thanks, >> >> --Gunnar >> >> [1] >> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos... >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi, I'm trying to perform a specific action upon transaction rollback. Assuming this could be done using a custom javax.transaction.Synchronization, I tried to register a synchronization as follows: TransactionImplementor transaction = ...; // e.g. a CMTTransaction transaction.registerSynchronization( new MySync() ); And indeed beforeCompletion() is invoked as expected. But afterCompletion() never is. I debugged this a bit on WildFly and observed the following: * Hibernate ORM registers RegisteredSynchronization with JTA. RegisteredSynchronization manages (indirectly, through TransactionCoordinator, SynchronizationRegistry etc.) those synchronizations added through o.h.t.Transaction.registerSynchronization() * WildFly (specifically, TransactionUtil [1]) registers its own SessionSynchronization for closing the entity manager/session Now that second synchronization is called first, closing the session. Upon SessionImpl#close(), the SynchronizationRegistry is cleared. Then when afterComplection() is called on RegisteredSynchronization afterwards, any previously registered delegate synchronizations are gone already and thus do not get invoked. I believe I found a workaround for my case by registering my synchronization through JtaPlatform#registerSynchronization() (which registers it with the actual JTA transaction). My questions are: * Is this behaviour expected? * Is the work-around of doing the registration via JtaPlatform viable or are there any drawbacks which I'm not aware of? Thanks, --Gunnar [1] https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

So Gunnar, your workaround is fine today but will pose problems in the future if we decide that onRollback for ErrorHandler needs access to the session somehow to be able to compensate and undo the already executed operations: - a closed session will do us no good - there is a harder problem that Scott mentions below related to tx reaping in a different thread Let’s try and find a solution for the first problem. @Scott, I think what happens is the following: - Hibernate registers a Sync when the EM is created (for the flush() callbacks and a few other things) - Synchronization attached to the Hibernate Transaction objects are piggybacking on that initial Sync attachement - Wildfly attach a “close session” Sync once it has the instance of EntityManager - according to your rules, the close session afterTransaction Sync is called before the one Hibernate put - that explains why Gunnar finds an already closed Tx. But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator creates the Hibernate transaction, which is when the EM is created, I can’t explain why the workaround works.

Emmanuel > On 10 Mar 2015, at 14:39, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > Hi Gunnar, > > Yes, this behaviour is expected since you registered an non-interposed > synchronization. For what purpose are you registering the transaction > synchronization? I would like to be aware of the synchronizations that > we register in WildFly. > > The non-interposed sync beforeCompletion callback are invoked first, > then the interposed sync beforeCompletion calls, then the interposed > afterCompletion(int status) calls and finally, the non-interposed > afterCompletion(int status) calls. > > The Synchronizations that are registered via the > javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) > [2] are interposed. > > Synchronizations that are registered via the > javax.transaction.Transaction.registerSynchronization(Synchronization) > [3] are non-interposed. > > In WildFly, the transaction manager uses the registration order within > the interposed/non-interposed group. Before completion syncs (within > their respective group), are run in registration order. After > completion syncs (within their respective group), are run in reverse > registration order. > > I believe that your workaround, mentioned below, of using > JtaPlatform#registerSynchronization() on WildFly, is registering your > synchronization as interposed via the TransactionSynchronizationRegistry > [2]. There might be a way to register a sync callback at the Hibernate > session level (which would also run as interposed sync on WildFly). > > Not sure if you saw my email yesterday to Hibernate-dev ml. You should > be aware that the afterCompletion(int status) callback, may be called > from a non-application thread when the WildFly tm reaper handles tx > timeout (this can happen while the application thread is still invoking > calls on the Hibernate session). Because the Hibernate session is not > thread safe, we need to ensure that the Hibernate session > afterCompletion(int status) callback does not mutate the Hibernate > session (e.g. calling session.clear() what status == rolled back). > > Scott > > [2] > http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron... > > [3] > http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#re... > > On 03/10/2015 09:03 AM, Gunnar Morling wrote: >> Hi, >> >> I'm trying to perform a specific action upon transaction rollback. >> >> Assuming this could be done using a custom >> javax.transaction.Synchronization, I tried to register a synchronization as >> follows: >> >> TransactionImplementor transaction = ...; // e.g. a CMTTransaction >> transaction.registerSynchronization( new MySync() ); >> >> And indeed beforeCompletion() is invoked as expected. But afterCompletion() >> never is. I debugged this a bit on WildFly and observed the following: >> >> * Hibernate ORM registers RegisteredSynchronization with JTA. >> RegisteredSynchronization manages (indirectly, through >> TransactionCoordinator, SynchronizationRegistry etc.) those >> synchronizations added through o.h.t.Transaction.registerSynchronization() >> * WildFly (specifically, TransactionUtil [1]) registers its own >> SessionSynchronization >> for closing the entity manager/session >> >> Now that second synchronization is called first, closing the session. Upon >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when >> afterComplection() is called on RegisteredSynchronization afterwards, any >> previously registered delegate synchronizations are gone already and thus >> do not get invoked. >> >> I believe I found a workaround for my case by registering my >> synchronization through JtaPlatform#registerSynchronization() (which >> registers it with the actual JTA transaction). >> >> My questions are: >> >> * Is this behaviour expected? >> * Is the work-around of doing the registration via JtaPlatform viable or >> are there any drawbacks which I'm not aware of? >> >> Thanks, >> >> --Gunnar >> >> [1] >> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos... >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 10 Mar 2015, at 14:39, Scott Marlow <smarlow(a)redhat.com&gt; wrote: Hi Gunnar, Yes, this behaviour is expected since you registered an non-interposed synchronization. For what purpose are you registering the transaction synchronization? I would like to be aware of the synchronizations that we register in WildFly. The non-interposed sync beforeCompletion callback are invoked first, then the interposed sync beforeCompletion calls, then the interposed afterCompletion(int status) calls and finally, the non-interposed afterCompletion(int status) calls. The Synchronizations that are registered via the javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) [2] are interposed. Synchronizations that are registered via the javax.transaction.Transaction.registerSynchronization(Synchronization) [3] are non-interposed. In WildFly, the transaction manager uses the registration order within the interposed/non-interposed group. Before completion syncs (within their respective group), are run in registration order. After completion syncs (within their respective group), are run in reverse registration order. I believe that your workaround, mentioned below, of using JtaPlatform#registerSynchronization() on WildFly, is registering your synchronization as interposed via the TransactionSynchronizationRegistry [2]. There might be a way to register a sync callback at the Hibernate session level (which would also run as interposed sync on WildFly). Not sure if you saw my email yesterday to Hibernate-dev ml. You should be aware that the afterCompletion(int status) callback, may be called from a non-application thread when the WildFly tm reaper handles tx timeout (this can happen while the application thread is still invoking calls on the Hibernate session). Because the Hibernate session is not thread safe, we need to ensure that the Hibernate session afterCompletion(int status) callback does not mutate the Hibernate session (e.g. calling session.clear() what status == rolled back). Scott [2] http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron... [3] http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#re... On 03/10/2015 09:03 AM, Gunnar Morling wrote: > Hi, > > I'm trying to perform a specific action upon transaction rollback. > > Assuming this could be done using a custom > javax.transaction.Synchronization, I tried to register a synchronization as > follows: > > TransactionImplementor transaction = ...; // e.g. a CMTTransaction > transaction.registerSynchronization( new MySync() ); > > And indeed beforeCompletion() is invoked as expected. But afterCompletion() > never is. I debugged this a bit on WildFly and observed the following: > > * Hibernate ORM registers RegisteredSynchronization with JTA. > RegisteredSynchronization manages (indirectly, through > TransactionCoordinator, SynchronizationRegistry etc.) those > synchronizations added through o.h.t.Transaction.registerSynchronization() > * WildFly (specifically, TransactionUtil [1]) registers its own > SessionSynchronization > for closing the entity manager/session > > Now that second synchronization is called first, closing the session. Upon > SessionImpl#close(), the SynchronizationRegistry is cleared. Then when > afterComplection() is called on RegisteredSynchronization afterwards, any > previously registered delegate synchronizations are gone already and thus > do not get invoked. > > I believe I found a workaround for my case by registering my > synchronization through JtaPlatform#registerSynchronization() (which > registers it with the actual JTA transaction). > > My questions are: > > * Is this behaviour expected? > * Is the work-around of doing the registration via JtaPlatform viable or > are there any drawbacks which I'm not aware of? > > Thanks, > > --Gunnar > > [1] > https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos... > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I believe that your workaround, mentioned below, of using

Hi Gunnar, Yes, this behaviour is expected since you registered an non-interposed synchronization. For what purpose are you registering the transaction synchronization? I would like to be aware of the synchronizations that we register in WildFly. The non-interposed sync beforeCompletion callback are invoked first, then the interposed sync beforeCompletion calls, then the interposed afterCompletion(int status) calls and finally, the non-interposed afterCompletion(int status) calls. The Synchronizations that are registered via the javax.transaction. TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) [2] are interposed. Synchronizations that are registered via the javax.transaction.Transaction. registerSynchronization(Synchronization) [3] are non-interposed. In WildFly, the transaction manager uses the registration order within the interposed/non-interposed group. Before completion syncs (within their respective group), are run in registration order. After completion syncs (within their respective group), are run in reverse registration order. I believe that your workaround, mentioned below, of using JtaPlatform#registerSynchronization() on WildFly, is registering your synchronization as interposed via the TransactionSynchronizationRegistry [2]. There might be a way to register a sync callback at the Hibernate session level (which would also run as interposed sync on WildFly). Not sure if you saw my email yesterday to Hibernate-dev ml. You should be aware that the afterCompletion(int status) callback, may be called from a non-application thread when the WildFly tm reaper handles tx timeout (this can happen while the application thread is still invoking calls on the Hibernate session). Because the Hibernate session is not thread safe, we need to ensure that the Hibernate session afterCompletion(int status) callback does not mutate the Hibernate session (e.g. calling session.clear() what status == rolled back). Scott [2] http://docs.oracle.com/javaee/5/api/javax/transaction/ TransactionSynchronizationRegistry.html#registerInterposedSynchronizat ion%28javax.transaction.Synchronization%29 [3] http://docs.oracle.com/javaee/5/api/javax/transaction/ Transaction.html#registerSynchronization%28javax.transaction. Synchronization%29 On 03/10/2015 09:03 AM, Gunnar Morling wrote: > Hi, > > I'm trying to perform a specific action upon transaction rollback. > > Assuming this could be done using a custom > javax.transaction.Synchronization, I tried to register a synchronization > as > follows: > > TransactionImplementor transaction = ...; // e.g. a CMTTransaction > transaction.registerSynchronization( new MySync() ); > > And indeed beforeCompletion() is invoked as expected. But > afterCompletion() > never is. I debugged this a bit on WildFly and observed the following: > > * Hibernate ORM registers RegisteredSynchronization with JTA. > RegisteredSynchronization manages (indirectly, through > TransactionCoordinator, SynchronizationRegistry etc.) those > synchronizations added through o.h.t.Transaction. > registerSynchronization() > * WildFly (specifically, TransactionUtil [1]) registers its own > SessionSynchronization > for closing the entity manager/session > > Now that second synchronization is called first, closing the session. Upon > SessionImpl#close(), the SynchronizationRegistry is cleared. Then when > afterComplection() is called on RegisteredSynchronization afterwards, any > previously registered delegate synchronizations are gone already and thus > do not get invoked. > > I believe I found a workaround for my case by registering my > synchronization through JtaPlatform#registerSynchronization() (which > registers it with the actual JTA transaction). > > My questions are: > > * Is this behaviour expected? > * Is the work-around of doing the registration via JtaPlatform viable or > are there any drawbacks which I'm not aware of? > > Thanks, > > --Gunnar > > [1] > https://github.com/wildfly/wildfly/blob/master/jpa/src/ > main/java/org/jboss/as/jpa/transaction/TransactionUtil.java > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

Gunnar, WildFly uses its own JtaPlatform... On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > Hi, > > > I believe that your workaround, mentioned below, of using > JtaPlatform#registerSynchronization() on WildFly, is registering your > synchronization as interposed via the TransactionSynchronizationRegistry > [2]. > > That seems not to be the case. If you check out AbstractJtaPlatform and > TransactionManagerBasedSynchronizationStrategy in ORM, > registerSynchronization() adds the Sync as non-interposed via > TransactionManager.getTransaction().registerSynchronization(). > > But the ordering is indeed what makes me wonder. As SessionSynchronization > is interposed, the non-interposed beforeCompletion() hooks are run, but > the > non-interposed afterCompletion() hooks managed via > RegisteredSynchronization are never run, as the session has been closed > and > thus the list of syncs to be invoked through RegisteredSynchronization has > been cleared at this point. At least this behaviour was surprising to me. > > My work-around works because my non-interposed sync is added through > JtaPlatform to the actual (Arjuna) Transaction instance directly (rather > than indirectly via RegisteredSynchronization) and thus gets invoked > properly. > > 2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow(a)redhat.com&gt;: > > > Hi Gunnar, > > > > Yes, this behaviour is expected since you registered an non-interposed > > synchronization. For what purpose are you registering the transaction > > synchronization? I would like to be aware of the synchronizations that > we > > register in WildFly. > > > > The non-interposed sync beforeCompletion callback are invoked first, > then > > the interposed sync beforeCompletion calls, then the interposed > > afterCompletion(int status) calls and finally, the non-interposed > > afterCompletion(int status) calls. > > > > The Synchronizations that are registered via the javax.transaction. > > > TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) > > [2] are interposed. > > > > Synchronizations that are registered via the > javax.transaction.Transaction. > > registerSynchronization(Synchronization) [3] are non-interposed. > > > > In WildFly, the transaction manager uses the registration order within > the > > interposed/non-interposed group. Before completion syncs (within their > > respective group), are run in registration order. After completion > syncs > > (within their respective group), are run in reverse registration order. > > > > I believe that your workaround, mentioned below, of using > JtaPlatform#registerSynchronization() > > on WildFly, is registering your synchronization as interposed via the > > TransactionSynchronizationRegistry [2]. There might be a way to register > > a sync callback at the Hibernate session level (which would also run as > > interposed sync on WildFly). > > > > Not sure if you saw my email yesterday to Hibernate-dev ml. You should > be > > aware that the afterCompletion(int status) callback, may be called from > a > > non-application thread when the WildFly tm reaper handles tx timeout > (this > > can happen while the application thread is still invoking calls on the > > Hibernate session). Because the Hibernate session is not thread safe, > we > > need to ensure that the Hibernate session afterCompletion(int status) > > callback does not mutate the Hibernate session (e.g. calling > > session.clear() what status == rolled back). > > > > Scott > > > > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/ > > TransactionSynchronizationRegistry.html#registerInterposedSynchronizat > > ion%28javax.transaction.Synchronization%29 > > > > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/ > > Transaction.html#registerSynchronization%28javax.transaction. > > Synchronization%29 > > > > > > On 03/10/2015 09:03 AM, Gunnar Morling wrote: > > > >> Hi, > >> > >> I'm trying to perform a specific action upon transaction rollback. > >> > >> Assuming this could be done using a custom > >> javax.transaction.Synchronization, I tried to register a > synchronization > >> as > >> follows: > >> > >> TransactionImplementor transaction = ...; // e.g. a CMTTransaction > >> transaction.registerSynchronization( new MySync() ); > >> > >> And indeed beforeCompletion() is invoked as expected. But > >> afterCompletion() > >> never is. I debugged this a bit on WildFly and observed the following: > >> > >> * Hibernate ORM registers RegisteredSynchronization with JTA. > >> RegisteredSynchronization manages (indirectly, through > >> TransactionCoordinator, SynchronizationRegistry etc.) those > >> synchronizations added through o.h.t.Transaction. > >> registerSynchronization() > >> * WildFly (specifically, TransactionUtil [1]) registers its own > >> SessionSynchronization > >> for closing the entity manager/session > >> > >> Now that second synchronization is called first, closing the session. > Upon > >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when > >> afterComplection() is called on RegisteredSynchronization afterwards, > any > >> previously registered delegate synchronizations are gone already and > thus > >> do not get invoked. > >> > >> I believe I found a workaround for my case by registering my > >> synchronization through JtaPlatform#registerSynchronization() (which > >> registers it with the actual JTA transaction). > >> > >> My questions are: > >> > >> * Is this behaviour expected? > >> * Is the work-around of doing the registration via JtaPlatform viable > or > >> are there any drawbacks which I'm not aware of? > >> > >> Thanks, > >> > >> --Gunnar > >> > >> [1] > >> https://github.com/wildfly/wildfly/blob/master/jpa/src/ > >> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

For some reason I'm seeing though JBossStandAloneJtaPlatform being used when debugging an OGM integration test on WildFly. WF's JtaPlatform seems not to be picked up. Tried to debug a but, apparently it never comes to the point where JipiJapa would inject the JBossAppServerJtaPlatform as platform. I could imagine it's due to OGM being used as persistence provider, so maybe the right implicit module dependencies don't get added? Scott? It's all a bit guess work on my side, I don't know that WF/JipiJapa code very well. 2015-03-10 16:50 GMT+01:00 Steve Ebersole <steve(a)hibernate.org <mailto:steve@hibernate.org>>: Gunnar, WildFly uses its own JtaPlatform... On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling <gunnar(a)hibernate.org <mailto:gunnar@hibernate.org>> wrote: Hi, > I believe that your workaround, mentioned below, of using JtaPlatform#registerSynchronization() on WildFly, is registering your synchronization as interposed via the TransactionSynchronizationRegistry [2]. That seems not to be the case. If you check out AbstractJtaPlatform and TransactionManagerBasedSynchronizationStrategy in ORM, registerSynchronization() adds the Sync as non-interposed via TransactionManager.getTransaction().registerSynchronization(). But the ordering is indeed what makes me wonder. As SessionSynchronization is interposed, the non-interposed beforeCompletion() hooks are run, but the non-interposed afterCompletion() hooks managed via RegisteredSynchronization are never run, as the session has been closed and thus the list of syncs to be invoked through RegisteredSynchronization has been cleared at this point. At least this behaviour was surprising to me. My work-around works because my non-interposed sync is added through JtaPlatform to the actual (Arjuna) Transaction instance directly (rather than indirectly via RegisteredSynchronization) and thus gets invoked properly. 2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>>: > Hi Gunnar, > > Yes, this behaviour is expected since you registered an non-interposed > synchronization. For what purpose are you registering the transaction > synchronization? I would like to be aware of the synchronizations that we > register in WildFly. > > The non-interposed sync beforeCompletion callback are invoked first, then > the interposed sync beforeCompletion calls, then the interposed > afterCompletion(int status) calls and finally, the non-interposed > afterCompletion(int status) calls. > > The Synchronizations that are registered via the javax.transaction. > TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) > [2] are interposed. > > Synchronizations that are registered via the javax.transaction.Transaction. > registerSynchronization(Synchronization) [3] are non-interposed. > > In WildFly, the transaction manager uses the registration order within the > interposed/non-interposed group. Before completion syncs (within their > respective group), are run in registration order. After completion syncs > (within their respective group), are run in reverse registration order. > > I believe that your workaround, mentioned below, of using JtaPlatform#registerSynchronization() > on WildFly, is registering your synchronization as interposed via the > TransactionSynchronizationRegistry [2]. There might be a way to register > a sync callback at the Hibernate session level (which would also run as > interposed sync on WildFly). > > Not sure if you saw my email yesterday to Hibernate-dev ml. You should be > aware that the afterCompletion(int status) callback, may be called from a > non-application thread when the WildFly tm reaper handles tx timeout (this > can happen while the application thread is still invoking calls on the > Hibernate session). Because the Hibernate session is not thread safe, we > need to ensure that the Hibernate session afterCompletion(int status) > callback does not mutate the Hibernate session (e.g. calling > session.clear() what status == rolled back). > > Scott > > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/ > TransactionSynchronizationRegistry.html#registerInterposedSynchronizat > ion%28javax.transaction.Synchronization%29 > > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/ > Transaction.html#registerSynchronization%28javax.transaction. > Synchronization%29 > > > On 03/10/2015 09:03 AM, Gunnar Morling wrote: > >> Hi, >> >> I'm trying to perform a specific action upon transaction rollback. >> >> Assuming this could be done using a custom >> javax.transaction.Synchronization, I tried to register a synchronization >> as >> follows: >> >> TransactionImplementor transaction = ...; // e.g. a CMTTransaction >> transaction.registerSynchronization( new MySync() ); >> >> And indeed beforeCompletion() is invoked as expected. But >> afterCompletion() >> never is. I debugged this a bit on WildFly and observed the following: >> >> * Hibernate ORM registers RegisteredSynchronization with JTA. >> RegisteredSynchronization manages (indirectly, through >> TransactionCoordinator, SynchronizationRegistry etc.) those >> synchronizations added through o.h.t.Transaction. >> registerSynchronization() >> * WildFly (specifically, TransactionUtil [1]) registers its own >> SessionSynchronization >> for closing the entity manager/session >> >> Now that second synchronization is called first, closing the session. Upon >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when >> afterComplection() is called on RegisteredSynchronization afterwards, any >> previously registered delegate synchronizations are gone already and thus >> do not get invoked. >> >> I believe I found a workaround for my case by registering my >> synchronization through JtaPlatform#registerSynchronization() (which >> registers it with the actual JTA transaction). >> >> My questions are: >> >> * Is this behaviour expected? >> * Is the work-around of doing the registration via JtaPlatform viable or >> are there any drawbacks which I'm not aware of? >> >> Thanks, >> >> --Gunnar >> >> [1] >> https://github.com/wildfly/wildfly/blob/master/jpa/src/ >> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev