That's a good question. For now we implicitly decided not to use a different tx I guess. Remember, there in no actual transaction in those NoSQL backends in the first place.
> On 10 mars 2015, at 16:36, Steve Ebersole <st...@hibernate.org> wrote: > > 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
