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
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
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
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.
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo