Isn't the general approach is for "compensating actions" to be run in a separate transaction?
On Tue, Mar 10, 2015 at 10:11 AM, Scott Marlow <smar...@redhat.com> wrote: > 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 <gun...@hibernate.org> 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@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 > > > _______________________________________________ > hibernate-dev mailing list > 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
