-
15. Re: Distributed transaction not rolledBack
Good. Your test isn't failing then :-)
setRollbackOnly is not propagated between distributed nodes in a transaction. For a start, that's an overhead that is not needed (all setRollbackOnly does is make sure the transaction will eventually roll back), and secondly it's not a requirement in JTA or JTS.
You also need to understand that when you are using the JTS, you'll be using interposition. So although the work done by EJBB is in the scope of the same global transaction, it is actually done within the scope of a separate subordinate transaction.
From what you've said, everything is behaving as I would expect: EJBB forces the transaction to rollback. It does this by calling setRollbackOnly which marks the local (subordinate) transaction as having to rollback, but it does not affect the root transaction state (yet). The root transaction will eventually try to commit and talk to the subordinate transaction which will say NO and force the entire global transaction to rollback.
If you want the capability for EJBB setRollbackOnly to affect the root transaction immediately, then you can turn interoposition off. See the programmers manuals for how to do that. However, interposition is often the best choice, so I'd recommend only doing this if you really know what you want to achieve. -
16. Re: Distributed transaction not rolledBack
"mark.little@jboss.com" wrote:
Good. Your test isn't failing then :-)
Good news :-)
setRollbackOnly is not propagated between distributed nodes in a transaction. For a start, that's an overhead that is not needed (all setRollbackOnly does is make sure the transaction will eventually roll back), and secondly it's not a requirement in JTA or JTS.
So, the application server is free to propagate it ?
You also need to understand that when you are using the JTS, you'll be using interposition. So although the work done by EJBB is in the scope of the same global transaction, it is actually done within the scope of a separate subordinate transaction.
From what you've said, everything is behaving as I would expect: EJBB forces the transaction to rollback. It does this by calling setRollbackOnly which marks the local (subordinate) transaction as having to rollback, but it does not affect the root transaction state (yet). The root transaction will eventually try to commit and talk to the subordinate transaction which will say NO and force the entire global transaction to rollback.
I understand this when the EJB B method is in "required" mode but when it is in "requiresNew" mode, I think that the EJB B 's transaction should rollback and the EJB A 's root transaction commit should success. Don't you agree ?
If you want the capability for EJBB setRollbackOnly to affect the root transaction immediately, then you can turn interoposition off. See the programmers manuals for how to do that. However, interposition is often the best choice, so I'd recommend only doing this if you really know what you want to achieve.
Ok, I'll read it soon.
Thanks ! -
17. Re: Distributed transaction not rolledBack
"trecloux" wrote:
So, the application server is free to propagate it ?
This has nothing to do with the application server. It's purely a transaction system issue.
I understand this when the EJB B method is in "required" mode but when it is in "requiresNew" mode, I think that the EJB B 's transaction should rollback and the EJB A 's root transaction commit should success. Don't you agree ?
If EJBB starts a completely new transaction then it is independent from EJBA's, so B should rollback and A should commit. If you've already said that was not happening, then I must have missed it. -
18. Re: Distributed transaction not rolledBack
If EJBB starts a completely new transaction then it is independent from EJBA's, so B should rollback and A should commit. If you've already said that was not happening, then I must have missed it.
I do not speak a good english, so I do not blam you :-)
I have got the same exception in required or requiresNew mode.
This scenario is :
- webapp calls EJB A method (required mode)
- EJB A updates DB
- EJB A calls EJB B method (requiresNew mode)
- EJB B updates DB
- EJB B calls setRollbackOnly
- EJB B returns
- EJB A returns
The Ejb A 's container throws a RollbackException on the TransactionImple.commit()
The updates of A & B beans or not commited in DB. -
19. Re: Distributed transaction not rolledBack
I just want to double check: if you rollback EJBA (don't setRollbackOnly in B, but in A), what happens now?
-
20. Re: Distributed transaction not rolledBack
"mark.little@jboss.com" wrote:
I just want to double check: if you rollback EJBA (don't setRollbackOnly in B, but in A), what happens now?
In this case, the rollback is successfull.
- When B is in "required" mode, the A & B updates are rollbacked.
- When A is in "requiresNew" mode, only the A updates are rollbacked. B updates are commited. -
21. Re: Distributed transaction not rolledBack
Before asking you to try something, I need just a little more information (just an extension of what you've put in the last entry). Can you fill in the following:
A setRollbackOnly: 'A "mode"' 'B "mode"' 'A transaction' 'B transaction'
B setRollbackOnly: 'A "mode"' 'B "mode"' 'A transaction' 'B transaction'
where 'A transaction' would be "commits" or "rolls back" and 'A "mode"' would be "required" or "requiresNew".
Then give me all of the combinations you have tried. I'm after the entire matrix of options and results in a single place. If that doesn't make sense, or you want more clarification, then send me an email. -
22. Re: Distributed transaction not rolledBack
"mark.little@jboss.com" wrote:
Before asking you to try something, I need just a little more information (just an extension of what you've put in the last entry). Can you fill in the following:
A setRollbackOnly: 'A "mode"' 'B "mode"' 'A transaction' 'B transaction'
B setRollbackOnly: 'A "mode"' 'B "mode"' 'A transaction' 'B transaction'
where 'A transaction' would be "commits" or "rolls back" and 'A "mode"' would be "required" or "requiresNew".
Then give me all of the combinations you have tried. I'm after the entire matrix of options and results in a single place. If that doesn't make sense, or you want more clarification, then send me an email.
A setRollbackOnly: 'A "required"' 'B "required"' ' A rollsback' 'B rollsback'
A setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B commits'
B setRollbackOnly: 'A "required"' 'B "required"' ' A rollsback' 'B rollsback'
B setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B rollsback'
Thanks for time spended with us. -
23. Re: Distributed transaction not rolledBack
Thanks. This is good. Let me go through each of the entries in turn and explain what I see. Then you can let me know if I've got it wrong.
"trecloux" wrote:
A setRollbackOnly: 'A "required"' 'B "required"' ' A rollsback' 'B rollsback'
Here A and B are in the same transaction. So when A rolls back (because of the setRollbackOnly) that will cause B to rollback. Which is what you've said you see. So this looks fine.
A setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B commits'
Here A and B are in different transactions. So when A rolls back (because of the setRollbackOnly) that will not cause B to rollback: it will commit independently. Which is what you've said you see. So this looks fine.
B setRollbackOnly: 'A "required"' 'B "required"' ' A rollsback' 'B rollsback'
Here A and B are in the same transaction. So when A rolls back (because of the setRollbackOnly in B, though it will try to commit first) that will cause B to rollback as well. Which is what you've said you see. So this looks fine.
B setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B rollsback'
Here A and B are in different transactions again. So A should commit (I'm assuming there's no other call to setRollbackOnly within A) and B will rollback because of the setRollbackOnly it called. Which is not what you're seeing: both A and B rollback.
Thanks for time spended with us.
No problem. Glad to help. -
24. Re: Distributed transaction not rolledBack
"mark.little@jboss.com" wrote:
B setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B rollsback'
Here A and B are in different transactions again. So A should commit (I'm assuming there's no other call to setRollbackOnly within A) and B will rollback because of the setRollbackOnly it called. Which is not what you're seeing: both A and B rollback.
OK, We agree : "A should not roll back (there is no other call to setRollbackOnly within A)".
What could I test ?
Do you want me to send you the source code of the sample application ? -
25. Re: Distributed transaction not rolledBack
Sure, mail me the code: with a build script so I don't have to do too much setup please ;-)
I'll take a look at it as soon as I can. That may be a day or so from now though. In the meantime, here's another suggestion: try disabling interposition and only using context propagation. I wouldn't expect this to make a difference to the results, but it should make it easier for us to track down the problem.
If you have any problems moving to context propagation please set up a new forum topic so we don't get this one any more confused. Thanks. -
26. Re: Distributed transaction not rolledBack
"mark.little@jboss.com" wrote:
Sure, mail me the code: with a build script so I don't have to do too much setup please ;-)
I'll take a look at it as soon as I can. That may be a day or so from now though. In the meantime, here's another suggestion: try disabling interposition and only using context propagation. I wouldn't expect this to make a difference to the results, but it should make it easier for us to track down the problem.
If you have any problems moving to context propagation please set up a new forum topic so we don't get this one any more confused. Thanks.
Hello,
We try to disable the interposition, but the behaviour seems to be the same.
We still have :
B setRollbackOnly: 'A "required"' 'B "required"' ' A rollsback' 'B rollsback' with TxRooledBackException
B setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B rollsback ' with TxRooledBackException
thx in advance. -
27. Re: Distributed transaction not rolledBack
"gwallet" wrote:
We still have :
B setRollbackOnly: 'A "required"' 'B "required"' ' A rollsback' 'B rollsback' with TxRooledBackException
B setRollbackOnly: 'A "required"' 'B "requiresNew"' 'A rollsback' 'B rollsback ' with TxRooledBackException
thx in advance.
As I indicated, this change shouldn't affect the results. It'll just make it easier to track down the problem.
In your EJB code (both A and B) try the following: get hold of the current transaction (via getTransaction) and call toString() on it.