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.
________________________________________________________________________________

Evan Ireland              Sybase EA Server Engineering       [EMAIL PROTECTED]
                            Wellington - New Zealand              +64 4 934-5856

===========================================================================
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".

Reply via email to