Doubts in client view of a session bean

[B.Sathish]

I just completed chapter 3 in HFEJB- client view of a session bean and after reeading this chapter, the following doubts have occured to me :

Handles to stateless session beans:
Why do we need a handle to a stateless session bean. I feel it is meaningless. Because if I am a client to a stateless session bean, I don't care which EJBObject I connect to, I am going to get some bean instance from the pool and I don't have any need to connect to any particular stateless session bean instance.

Remove on a stateless session bean:
Why would anyone want to call remove on a stateless session bean. First of all, there is nothing to be cleaned up (no state). And second, If I call remove on the EJBobject, which bean would get removed? All the beans are in the pool. I don't see any meaning in calling remove on a stateless session bean.

I dont know whether these questions are answered in the next chapter, but I thought I will ask the forum these questions.

[Peer Reynders]

Originally posted by B Sathish:
Why do we need a handle to a stateless session bean.

Its simply a mechanism to bypass having to go through JNDI and the Home interface again. It lets you conceivably greate the handle on one machine, transmit it to another machine which can then re-stablish the connection to the components without doing the whole JDNI/Home song and dance.

Originally posted by B Sathish:
Why would anyone want to call remove on a stateless session bean.

Its simply a matter of keeping the interface of both types of session beans consistent.
Also remember (in reference to both of your questions) that when the client has a reference to a stateless session bean, there is no way for the client to tell whether its dealing with a stateless session bean. A session bean is made stateless/stateful through the deployment descriptor. A create with arguments in the home interface is a dead giveaway that you are dealing with a stateful sessionbean.
However you could add client specific state to a (formerly) stateless session bean and reploy it as a stateful session bean without the client ever knowing.

[Raja Sagar Panamgipalli]

Hi Satish,
IMHO and earlier as Peer Reynders its about keeping the interfaces consistent.

Else We would have had seperate individual interfaces for both stateless and stateful session beans.I think more to do with the idea of making API generic.

Oops please correct me if happened...

Thanks & regards,
Sagar

[Pranav Shukla]

Hi Sathish,

Your question:

Why would anyone want to call remove on a stateless session bean.

Even the client of a stateless session bean consumes some resources on the EJB container in terms of the EJBObject instance on the server (I believe that is one EJBObject instance per client - please correct me if I have got it wrong). So when the client calls remove on the EJBObject stub the server can garbage collect/ reuse it for another SLSB client.