Hello Ole,
Tuesday, July 25, 2000, 10:59:44 AM, you wrote:
OH> 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?
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.
Stephan.
