Stephan Gruschke wrote:
>[cut]
> OH> The general rule is that application exceptions do _not_ cause
> OH> transaction rollback. If rollback is desired the bean can call
> OH> setRollbackOnly() before throwing the application exception.
> OH> See EJB1.1 section 12.2.1 and section 9.1.9.
> OH> The rationale for this behaviour is that the client might want
> OH> to recover from an application exception without throwing away
> OH> all the previous work done in the transaction.
>
> OH> I think the special case above is needed to get the same semantics
> OH> regardless of the transaction attribute.
>
> OH> This only goes for application exceptions. For system exceptions
> OH> the container _does_ rollback the current transaction.
>
> I don't think that an thrown exception would automatically result in
> an transaction rollback. Maybe some application programmer would
> design his bean to throw an exception if the last entity of his
> current list was reached. But that wouldn't imply that the transaction
> was a failure.
This is true for application exceptions.
But for other exceptions and errors, EJB mandates that the
transaction (if any) be rolled back and the bean instance be
discarded.
Such exceptions are often unexpected and may leave the bean
instance in an inconsistent state.
EJB1.1 concludes in section 12.2.2:
"This means that the Bean Provider does not have to perform
any cleanup actions before throwing a non-application exception.
It is the Container that is responsible for the cleanup."
Best Regards,
Ole Husgaard.
