Dan Christopherson wrote:
>[cut]
> > > R�> As it says in the EJB spec is the preferred way ;-) (i.e. go look it up)
> > > Well the ejb spec states that the original exception should be thrown.
> > > That's clear.
> >
> > Almost. The exact behavior is specified in EJB spec. section 12.3.1.
> > If the container just started a transaction on the home.create() call
> > (RequiresNew attribute, for example), it should try to commit the
> > transaction before throwing the application exception (unless
> > setRollbackOnly() was called in which case the transaction must be
> > rolled back).
> The default behavior being a commit is a little surprising to me: if I
> throw an exception, it seems to strongly imply that what I was trying
> didn't work and I probably want to roll it back. Can anyone shed light on
> this for me?
The general rule is that application exceptions do _not_ cause
transaction rollback. If rollback is desired the bean can call
setRollbackOnly() before throwing the application exception.
See EJB1.1 section 12.2.1 and section 9.1.9.
The rationale for this behaviour is that the client might want
to recover from an application exception without throwing away
all the previous work done in the transaction.
I think the special case above is needed to get the same semantics
regardless of the transaction attribute.
This only goes for application exceptions. For system exceptions
the container _does_ rollback the current transaction.
Best Regards,
Ole Husgaard
