Evan Ireland wrote:
> Richard Monson-Haefel wrote:
> >
> > > ...
> >
> > This is not how the specification is worded. Referring to Table 8 of the Public
> > Release 2, in the third row where the scope of the transaction is delimited by the
> > bean method and its an application exception type:
> >
> > The bean can choose to invoke setRollbackOnly() before throwing an Application
> > Exception. If this occurs, the spec says that the container must re-throw the
> > application exception. So the client can *not* know the disposition of the bean's
> > transaction. The bean should be required to throw a system exception if it chooses
>to
> > invoke setRollbackOnly( ) otherwise there is absolutely now way for the client to
> > determine if the transaction was successful or not.
>
> We went through a similar issue with some of our customers before EJB 1.0, with
> the following result. If the bean calls setRollbackOnly() and throws an
> application exception, it should be an application exception that is
> 'understood' by the client to mean the transaction was rolled back.
This seems reasonable to me. As Assaf Arkin pointed out to me in an e-mail on this
topic:
EJB dumbs-down the Tx programming model a little which makes developers a lot more
productive, but you loose some of fine grained control and error handling that you get
using a low level Tx API like OTS.
--
Richard Monson-Haefel
EJB Expert for jGuru.com
( http://www.jguru.com )
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
( http://www.ejbnow.com )
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
