On Mon, Mar 09, 2015 at 09:26:34PM -0500, Steve Ebersole wrote:
> I tried using the feedback approach with Atlassian, lets see how that goes
> and whether we hear back. If I don't hear back in a few days, I will reach
> out to them directly.
+1 I guess this is related to their latest changes. May
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.registerSy
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
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, 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
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
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
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 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
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 03/10/2015 11:44 AM, Steve Ebersole wrote:
> Scott, I am not following. Pardon me if I am being dense :)
>
> Today, in our afterCompletion hooks we have code that, in the case of
> rollback, tries to make a determination of whether the rollback is due
> to a timeout or a "normal" rollback. I
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
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
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.
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
On 03/10/2015 12:30 PM, Steve Ebersole wrote:
> You confused me more :)
>
> One the one had you say that we will use this fact of whether the
> transaction has been disassociated to indicate whether the transaction
> is completing normally (disassociated == true) or timed-out
> (disassociated == fa
>
> So what is this buying us?
>
The current Hibernate ORM thread id checking, does not properly handle
the case when the application thread changes between calls to the
Hibernate session. The new approach does handle the application thread
changing between session invocations and also covers
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
I wanted to given everyone a heads up that I just pushed the work I have
been doing up to master. It is alot. It covers most of what was planned
as required for 5.0. The only outstanding item from that initial work is
to integrate the changes into Envers, but I was still waiting to hear back
fro
19 matches
Mail list logo
