System Exception Confusion

[Oliver Rensen]

Hello ranchers,

I'm fighting with system exceptions because I'm confused by the following:

a) Head First EJB, Page 546:
If the bean throws a system exception:
- throw a RemoteException if the client is remote
- throw an EJBException if the client is local

This means, that the bean can throw several system exceptions, but the client will get ONLY TWO system exceptions: RemoteException or EJBException.

Is my assumption correct?

b) Head First EJB, Page 558:
Client calls a method on a Remote CMT bean, and the method is marked Mandatory. The caller does not have a transaction context in place when the call comes in. The client gets a TransactionRequiredException.

I think, this is not correct, because TransactionRequiredException is a system exception. The bean will throw TransactionRequiredException, but the client will get a RuntimeException, and this RuntimeException wraps a TransactionRequiredException.

c) Head First EJB, Page 559:
Client calls remove() on a bean that's already been removed. Remote clients get RemoteException, and local clients get EJBException.

That's OK, but it's a little bit misleading, because the bean throws a NoSuchObjectException, the container wraps it in a RemoteException and throw this RemoteException to the client.

Remote clients get RemoteException (wrapping a NoSuchObjectException) and local clients get EJBException (wrapping a NoSuchObjectLocalException).

Is this supplement correct?

Regards,
Oliver

[Roger Chung-Wee]

a) Head First EJB, Page 546:
If the bean throws a system exception:
- throw a RemoteException if the client is remote
- throw an EJBException if the client is local

This means, that the bean can throw several system exceptions, but the client will get ONLY TWO system exceptions: RemoteException or EJBException.

Is my assumption correct?

Yes, and note that subclasses of these exceptions are sometimes thrown by the container to the client.

b) Head First EJB, Page 558:
Client calls a method on a Remote CMT bean, and the method is marked Mandatory. The caller does not have a transaction context in place when the call comes in. The client gets a TransactionRequiredException.

I think, this is not correct, because TransactionRequiredException is a system exception. The bean will throw TransactionRequiredException, but the client will get a RuntimeException, and this RuntimeException wraps a TransactionRequiredException.

c) Head First EJB, Page 559:
Client calls remove() on a bean that's already been removed. Remote clients get RemoteException, and local clients get EJBException.

That's OK, but it's a little bit misleading, because the bean throws a NoSuchObjectException, the container wraps it in a RemoteException and throw this RemoteException to the client.

Remote clients get RemoteException (wrapping a NoSuchObjectException) and local clients get EJBException (wrapping a NoSuchObjectLocalException).

Is this supplement correct?

You are incorrect on both counts. The requests never get to the bean as the container steps in and throws the appropriate exceptions to the client.

[Oliver Rensen]

Roger, thanks for your help, but I still don't understand, why the client in example c) will get a RemoteException and not a NoSuchObjectException from the container. HF EJB always wrotes, that a NoSuchObjectException will be thrown, when a client tries to call a method on a home- or component-stub, whose bean is already removed. Why is a NoSuchObjectException not involved in example c) ?

[Mahara J]

Hi !
Refer EJB 2.0 specification Page 375(18.3.1)
Its easy to understand and it will clear your doubt.

[Oliver Rensen]

Mahara, thanx for your advice. I have read the exception-spec today and I'm still confused. Page 379, section 18.3.5 in the spec says: If a client makes a call to a session object that has been removed, the Container should throw the NoSuchObjectException to a remote client, or the NoSuchObjectLocalException to a local client.

But Head First EJB wrotes on page 559:
Client calls remove() on a bean that's already been removed. Remote clients get RemoteException, and local clients get EJBException.

This is a contradiction between spec and HF EJB, isn't it?

[Peer Reynders]

Originally posted by Oliver Roell:
Page 379, section 18.3.5 in the spec says: If a client makes a call to a session object that has been removed, the Container should throw the NoSuchObjectException to a remote client, or the NoSuchObjectLocalException to a local client.

This sounds like the client is invoking a method on the EJB Object (which is no longer associated with a bean). Well actually its talking to the stub that may no longer be connected to an EJB Object but thats a different story.

Originally posted by Oliver Roell:

But Head First EJB wrotes on page 559:
Client calls remove() on a bean that's already been removed. Remote clients get RemoteException, and local clients get EJBException.

This is a contradiction between spec and HF EJB, isn't it?

The remove() method is on the EJB Home object (or the stub that talks to it). So the first relates to EJB Object while the second to EJB Home - apples and oranges - no contradiction.

[Sven Thor]

If you scroll down six posts in the topic list you will see that I posted the exact same question earlier today about the scenario "Client calls remove() on a bean that's already been removed" on p. 559 i HF EJB. I also don't understand it.

Why don't the client receive a NoSuchObjectException? From the replies I have read I still can't figure this out.

On the EJB object, or more precisely its stub, you can call remove(). I would assume this call to remove() to be treated as any other business method call. The way I understand "a bean that has already been removed" is that both the bean object and the ejb object are gone. So assuming the call from the stub reaches the container, the container will not find any ejb object to handle the remove() call. I would then think it should throw an NoSuchObjectException back to the client.

BTW, looking at the stack trace it seems like a NoSuchObjectException is thrown first and then wrapped in a RemoteException.

Br,
Sven T.

[Peer Reynders]

OK, so apparently we are talking EJBObject.remove() here, not EJBHome.remove() (My mistake)

BTW, that particular page has already one confirmed and one unconfirmed error. Bugs abhor loneliness (i.e. they like to travel in groups).

Originally posted by Sven Thor:
If you scroll down six posts in the topic list you will see that I posted the exact same question earlier today about the scenario "Client calls remove() on a bean that's already been removed" on p. 559 i HF EJB. I also don't understand it.

Why don't the client receive a NoSuchObjectException? From the replies I have read I still can't figure this out.

On the EJB object, or more precisely its stub, you can call remove(). I would assume this call to remove() to be treated as any other business method call. The way I understand "a bean that has already been removed" is that both the bean object and the ejb object are gone. So assuming the call from the stub reaches the container, the container will not find any ejb object to handle the remove() call. I would then think it should throw an NoSuchObjectException back to the client.

BTW, looking at the stack trace it seems like a NoSuchObjectException is thrown first and then wrapped in a RemoteException.

Br,
Sven T.

When it comes to certification guides - the specification is gospel.

So far I found several sections that support your position:

"7.6 STATEFUL Session Bean State Diagram
...
When the client calls remove on the home or component interface to remove the session object, the container issues ejbRemove() on the bean instance. This ends the life of the session bean instance and the associated session object. Any subsequent attempt by its client to invoke the session object causes the java.rmi.NoSuchObjectException to be thrown if the client is a remote client, or the javax.ejb.NoSuchObjectLocalException if the client is a local client. (The java.rmi.NoSuchObjectException is a subclass of the java.rmi.RemoteException; the javax.ejb.NoSuchObjectLocalException is a subclass of the javax.ejb.EJBException). The ejbRemove() method cannot be called when the instance is participating in a transaction. An attempt to remove a session object while the object is in a transaction will cause the container to throw the javax.ejb.RemoveException to the client. Note that a container can also invoke the ejbRemove() method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired."

"7.6.2 Dealing with exceptions
A RuntimeException thrown from any method of the session bean class (including the business methods and the callbacks invoked by the Container) results in the transition to the �does not exist� state. Exception handling is described in detail in Chapter 18. From the client perspective, the corresponding session object does not exist any more. Subsequent invocations through the remote interface will result in java.rmi.NoSuchObjectException; subsequent invocations through the local interface will result in javax.ejb.NoSuchObjectLocalException."

"10.3.4.1 Remove methods
...
The Container must detect any subsequent attempt to invoke an accessor method on the removed entity object and throw the java.rmi.NoSuchObjectException if the client is a remote client or the javax.ejb.NoSuchObjectLocalException if the client is a local client. The Container must detect an attempt to assign a removed entity object as the value of a cmr-field of another object (whether as an argument to a set accessor method or as an argument to a method of the java.util.Collection API) and throw the java.lang.IllegalArgumentException."

"18.3.5 Non-existing session object
If a client makes a call to a session object that has been removed, the Container should throw the java.rmi.NoSuchObjectException (which is a subclass of java.rmi.RemoteException) to a remote client, or the javax.ejb.NoSuchObjectLocalException to a local client."

So that scenario may simply be incorrect.

[Roger Chung-Wee]

NoSuchObjectException IS-A RemoteException, so there is no conflict.

[Peer Reynders]

Originally posted by Roger Chung-Wee:
NoSuchObjectException IS-A RemoteException, so there is no conflict.

java.rmi.NoSuchObjectException IS-A java.rmi.RemoteException
javax.ejb.NoSuchObjectLocalException IS-A javax.ejb.EJBException

Now there's a slick little exam question hiding in there.

The implementation has to throw java.rmi.NoSuchObjectException/ javax.ejb.NoSuchObjectLocalException otherwise its in violation of the spec.

But it is perfectly legal to claim that a java.rmi.RemoteException/ javax.ejb.EJBException is thrown - even if that doesn't tell the entire story.

Well, they do tell you to select the answer which is the MOST correct.
[ August 21, 2005: Message edited by: Peer Reynders ]

[Oliver Rensen]

Peer and Roger, thanks a lot for your clarification and explanations. I think, my confusion about system exceptions is now resolved.

Regards,
Oliver