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!
Greetz, Jef
[ August 10, 2004: Message edited by: Jef Cumps ]