Dan OConnor wrote:
> On 12 Apr 00, at 11:13, Richard Monson-Haefel wrote:
> >
> > This depends on how you want RemoteException thrown by other beans to be handled.
> > Transactions in EJB 1.1 are always rollback in the event of a EJBException is
>thrown
> > but not always for RemoteException. As David pointed out, you can choose to
>propagate
> > the RemoteException thrown by another bean to the client.
> >
> Hi Richard,
>
> Can you clarify this point for me? I understand that checked
> exceptions normally do not automatically roll back the transaction
> (to give the client an opportunity to recover), and also do not result
> in the eviction of the instance from the container. But 12.3.7
> seems to make RemoteException a special case:
>
> "The EJB 1.1 specification requires that a Container support the
> deprecated use of the java.rmi.RemoteException. The Container
> should treat the java.rmi.RemoteException thrown by an enterprise
> bean method in the same way as it is specified for the
> javax.ejb.EJBException."
>
> Because EJBException is an unchecked exception, and
> RemoteException should be treated the same as EJBException, it
> seems to me that RemoteException should be treated by the
> container as if it were unchecked.
>
> I believe that this is necessary for backwards compatibility. For
> instance, if a bean in ejbCreate throws a RemoteException (rather
> than EJBException, as is allowed) with the expectation that it does
> not need to write recovery code, this contract will be broken if the
> instance is not evicted from the container or if the transaction is not
> marked for rollback.
>
RemoteExceptions thrown by beans do not always denote a "system failure", but can be
thrown
to indicate a transaction rollback as well, which may OR may not be recoverable. For
Example: If bean 'A' invokes a method on bean 'B' AND bean 'B' executes the method in
its
own independent transaction context, a failure by bean 'B' will result in a
RemoteException
being thrown to bean 'A'. In this case, bean 'A' transaction is not affected by the
bean
'B''s exception. If its an entity bean or stateless session bean, bean 'A' can try the
operation again (possibly with different parameters). If it fails a second time then
bean
'A' should probably throw its own EJBException.
On the other hand, if bean 'B' executed under the same transaction context and bean
'A',
then bean 'A' should throw a EJBException (resulting in a RemoteException thrown to
bean 'A'
client) to clearly communicate the failure of the transaction.
As you can see exception handling in EJB is not black and white. Its complex and
requires
thought and design. It can be, as you pointed out, a good policy to simply re-throw
any
system exception as a EJBException to create a consistent contract between a bean and
its
clients.
Section 12.2.2 of the Specification supports either option. It provide the following
guidelines for handling system exceptions (it includes RemoteException in it
definition of
system exception. Some other examples of system exception include JVM errors,
RuntimeExceptions, SQLException, NamingException, JMSException, etc.)
" If the bean method encounters a RuntimeException or error, it should simply
propagate
the error from the bean method to the Container (i.e. the bean method does not have to
catch
the exception).
If the bean method performs an operation that results in a checked exception [15]
that the
bean
method cannot recover, the bean method should throw the javax.ejb.EJBException
that wraps the original exception.
Any other unexpected error conditions should be reported using the
javax.ejb.EJBEx-ception.
"
Hope this helps,
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition
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".
