Exceptions

[Ralph Jaus]

Dear all,

suppose a session bean with CMT and a business method that is performed in a newly started transaction. If the method throws an application exception there are two scenarios for the container's action (ejb core spec page 361, table 14, first row):

a) if setRollbackOnly() was called in the method, then rollback the transaction
b) if the application exception is specified as causing rollback, then mark the transaction for rollback.

Why behaves the container different in these cases ? That means, why doesn't the container rollback the transaction in b), too ?

Or is marking a transaction for rollback through the container the same as if the container performs a rollback ?
[ October 29, 2008: Message edited by: Ralph Jaus ]

[Christophe Verré]

why doesn't the container rollback the transaction in b), too

You could have thrown a application exception whose rollback attribute was set to false : @ApplicationException(rollback=false). It's useful when you want to stop a process when an error occured, but you want the transaction to keep going.

In scenario a, the transaction was explicitly rolled back, so no matter what kind of application exception was thrown, the transaction will be rolled back.

[Ralph Jaus]

Hi Christophe,

in the described scenario b) the rollback attribute of the application exception is set to true. And then the spec says: The container marks the transaction for rollback.

But why doesn't the container perform the rollback directly as he does in a) ?
[ October 30, 2008: Message edited by: Ralph Jaus ]

[Christophe Verré]

When calling setRollbackOnly, the container instructs the transaction manager to mark the transaction for rollback.
In b), setRollbackOnly is not called, so if the application exception is set to rollback the transaction, the container marks the transaction for rollback. In both cases, the transaction will finally be rolled back. I don't think you need to think too deeply about it

[Ralph Jaus]

Thanks for the explanation, Christophe.