Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

HFEJB - calling remove confusion

 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings folks,

On page 559 of Head First EJB, the first client scenario informs us that calling remove() on a bean that has already been removed will result in a RemoteException for remote clients, EJBException for local clients and moreover, that the result is the same as calling any business method on a removed bean.
Reading this, I am no longer sure when a NoSuchObjectException is thrown. My understanding was that NoSuchObjectException is thrown in cases where the RemoteObject has been removed. See Pg 554 with its wood chipper reference!

Any clarification would be appreciated!

regards
Simon
 
james edwin
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Quote from EJB2.0 specfication
**********************************************
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).
*********************************************
Unquote

And is signature of remove method as follows:-
public void ejbRemove() throws EJBException, java.rmi.RemoteException


So Local client will always get EJBException and and Remote client will always get RemoteException.

If anybody can put more light on this..that will be great.

James
 
Shahfazal Mohammed
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hiya there-

I'm just back from a graduation party for one of my friends, but guess i'm sensible/sane/sober enough to discuss this . The Container is free to throw any of the related exception to the client, meaning it can either throw a NoSuchObjectException or a RemoteException.

HFEJB page#550 - 'BANG!' note

The client might NOT get the most specific exception
'...The Container might not, according to the spec, send the client a DuplicateKeyException even if that is the problem... .. It's upto the Container whether it gives you the more specific exception'

So, I guess the exception thrown .. RemoteException or NoSuchObjectException .. really depends on the implementation of the Container

HTH,
- Fazal.
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does this mean, then that in the exercise on page 561 we simply put RemoteException for all entries in the left column and EJBException in the right column. In fact, why not do away with all the other exceptions? The Bang note seems like an admission of failure to me.

regards
Simon
 
Suman Sarker
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Lets see what the spec says about this

EJB spec page 379, section 18.3.5

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.


And the same is true for Entity beans as well.

Regards
Suman
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does this mean, then that in the exercise on page 561 we simply put RemoteException for all entries in the left column and EJBException in the right column. In fact, why not do away with all the other exceptions? The Bang note seems like an admission of failure to me.

Nope, that would be wrong for two reasons.

1. RemoteException is not always the answer. For instance, it is not thrown if a client call remove() on a stateful session bean that is in a transaction.

2. Even when RemoteException must be thrown, you should know which subclass of RemoteException the Container should throw.
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are, of course, right Roger. I was being ironic when I suggested that we fill out the table on page 561 with just RemoteException and EJBException. My real point was that the more specific exceptions are of much greater value than the less specific and page 549 clearly shows, so allowing the container the freedom to do a bad job seems a bit "un-Sun" like. Anyway, its all clear now, so thanks.

Simon
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic