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 ]
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.
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
Joined: Apr 27, 2008
Thanks for the explanation, Christophe.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com