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.
On 12 Apr 00, at 13:54, Richard Monson-Haefel wrote:
> 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.
Hi Richard,
I appreciate your response, which I think does a good job of
explaining many of the issues involved in EJB exception handling.
Sorry to keep after this, but I'm still not sure that there is any
difference between throwing a RemoteException and an
EJBException, even after your explanation. Could I take one more
try at explaining my reading of the specification?
It is certainly true that a client executing in a transaction that
receives a RemoteException may not have that transaction rolled
back. The remote method call may never have even reached the
server because of a communication error, for instance. So your
point that bean 'A' can retry bean 'B' after receiving a
RemoteException is certainly true. And if bean 'B' executes in its
own transaction context, of course its failure won't necessarily
mean that 'A''s transaction is rolled back.
But in the case of a bean throwing RemoteException, rather than a
client receiving a RemoteException, I think that the current
transaction will be marked for rollback and the instance will be
discarded, exactly as if an EJBException had been thrown. You
seemed to be saying that there was a difference when throwing
these transactions from a bean: "Transactions in EJB 1.1 are
always rollback in the event of a EJBException is thrown but not
always for RemoteException."
I base my reading of the spec on 12.3.7, cited in my last e-mail,
which says that the container should treat RemoteException and
EJBException as equivalent.
Also, 12.6 (Differences from EJB 1.0) says:
"In EJB 1.1, all non-application exceptions thrown by the instance
result in the rollback of the transaction in which the instance
executed, and in discarding the instance. In EJB 1.0, the Container
would not rollback a transaction and discard the instance if the
instance threw the java.rmi.RemoteException."
Sorry to continue with this if I misunderstood you, or have missed
something obvious in the spec. I totally agree with you that
exception handling in EJB is complex and requires thought and
design. Thanks for taking the time to spell out some of the issues.
-Dan
>
> 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".
>
===========================================================================
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".
