-
15. Re: tx aware cache config issue
It is good now, thanks, probably I would just change the level of this log:
13:54:48,274 WARN [TransactionTable] status is 1 (not ACTIVE or PREPARING); returning null) -
16. Re: tx aware cache config issue
Thinking of it a little bit more, I think a more passive behavior when setRollbackOnly is used would be better, since when invoking it in the transaction manager still allows you to do anything, just the commit will fail.
This behavior is also considered at least in JAIN-SLEE, where you can read and set any state, it just won't be committed.
What do you think? -
17. Re: tx aware cache config issue
No, that doesn't work for us since we need to register synchronizations with the TM for cache operations. If the transaction is marked as rolled back, TMs will not accept any new syncs being registered as per the JTA spec. So this means the cache cannot meaningfully operate in a tx if its status is MARKED_ROLLBACK, and hence the exception.
-
18. Re: tx aware cache config issue
Do we really need need a sync on the TM for this case, couldn't we just not do any changes, the opposite of the "old" behavior, which was like a auto commit?
-
19. Re: tx aware cache config issue
Yes we do, since, for example, we do:
tm.begin()
tm.setRollbackOnly()
cache.put() // assume this is a no-op since we have set rollback only
cache.get() // this call will return incorrect information based on the put() being a no-op. And this is wrong.
tm.commit() -
20. Re: tx aware cache config issue
What if you allowed the set rollback = true state when there is a sync already registred with the tx manager, this way I could always force it in the beginning of each transaction.
With this behavior my only solution is trapping setRollbackOnly(), which opens the door for a situation where the user uses the JTA tx manager outside of the container when integrating with a j2ee app, and the cache will then fail.
--Eduardo -
21. Re: tx aware cache config issue
I suppose that is something I could do, just not overly pleased with the inconsistent behaviour that will arise when a cache op is called with a tx which has been marked for rollback, depending on whether a sync is already registered or not. TBH, I'd much prefer consistent behavoiur.
What you could do is wrap the cache calls in a try block, and if you get an ISE then skip the cache step altogether since you know the tx will roll back. -
22. Re: tx aware cache config issue
Unfortunately I can't do that, the specs (including its tck) mandate the "passive" behavior, the user app may set or retrieve state before or after setRollbackOnly() is called.
I don't see this solution as inconsistent, it is just JBC being completely neutral, something as "ok I will let you go as long as I can know when the tx ends". -
23. Re: tx aware cache config issue
Any idea when the current -SNAPSHOT will support this behavior? I need it to close the task around the JAIN SLEE transaction manager and cache related code.