|
Problem |
Exception processing varies according to
EJB™ interface types and exception types. What happens in these
cases? |
|
|
|
Solution |
The basic answer to these questions can be found in
Section 18.3.1 of the 2.1 EJB Specification. It states:
1. Application Exceptions, those exceptions listed in a bean method's
throws clause, will be returned to the client as is. Note that
Runtime/System exceptions are never considered to be Application
Exceptions even if they are included on the throws clause per the EJB
specification.
2. When the bean method runs in the context of the caller's transaction
(i.e. Required, Mandatory,Supports), then the client must receive a
TransactionRolledbackException. Note: It is an ORB limitation that these
exceptions cannot nest exceptions and therefore we include as much
information as we can in the text. The ORB will strip out all nested
exceptions.
3. When the bean method runs in the context of a transaction that the
Container started immediately before dispatching the business method (i.e.
REQUIRED when a transaction doesn't previously exist, RequiresNew, and
NotSupported), then the client is required to receive a RemoteException.
We currently send TransactionRolledBackException, which is a subclass of
RemoteException and therefore compliant with the spec. We will be changing
to detect this situation and return a generic RemoteException with nested
exceptions.
In the local interface case the Container is required to send either
TransactionRolledbackLocalException or EJBException, both of which should
nest all appropriate exceptions. |
|
|