This pertains to the text on pg.486 of HFE regarding BMT transactions participants calling setRollBackOnly instead of rollback.I missed the point- about why it should proceed at all..? Can someone explain?
I guess calling setRollbackOnly() instead of rollback() is in some cases 'cleaner' programming. Suppose A starts a tx, calls B for doing some work propagating the tx, then A continous, maybe calling C and D, to either commit or rollback at the end of the ride.
If you're programming B, you know that you will be called with an incoming tx, but you don't know what's happening before or after you. IMHO, it's nicer and cleaner for B to not rollback the tx, but instead mark it for rollback (call setRollbackOnly()). It's B's responsability to decide wether his part went wrong and should be rolled back, but it's A's decision to oversee the whole process, and do the actual rollback, based on what the called methods/beans/components did...
You could imagine a process (method) for A that calls B, then B marks the tx for rollback and returns, A checks the rollback-status, and (maybe at the end) calls C to log that something went wrong ... or something. :roll:
When using this technique, you should really make sure that A doesn't do a lot of work when the tx is already marked for rollback. So use getStatus() to check this before doing something that could use sparse resources when the tx is already doomed!
That makes sense; I got stumped because in my mind, A(which initiated the tx) encountered a condition which justified rolling back - why would it proceed with calling other methods when it knows right away and can make that decision.You clarified it though; the provision seems to be for scenarios where such conditions are encountered by other beans which are called.
Originally posted by Anirudh Borkar: This pertains to the text on pg.486 of HFE regarding BMT transactions participants calling setRollBackOnly instead of rollback.I missed the point- about why it should proceed at all..? Can someone explain?
The reason given here was that the typical scenario where you could use the rollback method is at the end of the method, depending if things look good (and in this case you'd commit) or look bad (and in this case you'd rollback). But the above scenario would normally happen at the end of a method. On the other side, if you know that your transaction is going to end badly, and because BMT transaction can propagate their transaction context to other CMT beans (not vice-versa), and CMT beans can check the transaction status via getRollbackOnly method, then you have a possibility of being a *good* network citizen, giving a chance to other *good* network citizens to shorten a failing process, thus increasing performance.
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
I knew I would regret that burrito. But this tiny ad has never caused regrets: