Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-12 Thread Steve Ebersole
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 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, Emmanu

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Scott Marlow
Not exactly sure but this might be the way that Jipijapa registers the JtaPlatform. Originally, Jipijapa used the service approach but reverted that due to a memory leak (I think in envers?). This was mentioned a while back via [3]. I think we talked about switching Jipijapa back to using a

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Steve Ebersole
Ah, that could be. Jipijapa does do a lot of things specific to the provider used. Probably we just need some proper OGM Jipijapa hooks. On Tue, Mar 10, 2015 at 12:14 PM, Gunnar Morling wrote: > For some reason I'm seeing though JBossStandAloneJtaPlatform being used > when debugging an OGM int

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Gunnar Morling
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.

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Emmanuel Bernard
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 wrote: > > Isn't the general approach is for "compensating actions" to be

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Emmanuel Bernard
I think we would need the same concurrency protection yes. If not today, in the near future. > On 10 mars 2015, at 15:53, Scott Marlow wrote: > > > >> On 03/10/2015 10:12 AM, Emmanuel Bernard wrote: >> So Gunnar, your workaround is fine today but will pose problems in the >> future if we d

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Gunnar Morling
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 TransactionMa

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Steve Ebersole
On Tue, Mar 10, 2015 at 8:39 AM, Scott Marlow wrote: > > > 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 reg

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Scott Marlow
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

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Scott Marlow
On 03/10/2015 10:12 AM, Emmanuel Bernard wrote: > 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 s

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Emmanuel Bernard
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. Your workaround seems fine (if there is a JtaPlaform) but when we add more logic to your onRollback calls, we might want to offer

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Emmanuel Bernard
Scott, for Hibernate OGM and for non transactional datastores, we collect the list of executed operations and offer the list if the user calls Hibernate’s transaction.rollback() or if the JTA transaction is rollbacked. Note that the JTA transaction has no resource attached to it since the datast

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Emmanuel Bernard
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

Re: [hibernate-dev] JTA synchronizations on WildFly

2015-03-10 Thread Scott Marlow
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 call