When you deploy the ejb the container generates the stub classes for you and also creates the classes that implements the EJBHome and EJBObject. These are proxy classes (Proxy pattern) and has code to communicate(marshalling and unmarshalling) with the corresponding EJBObject and EJBHome classes. So during run time when a client make a call to the proxy object it communicates with the cooreponding Remote EJBObject and EJBHome to transfer the call. When you remove the Bean by calling remove on the EjbObject or home interface the Bean is destroyed (Stateful Session Bean) the EJBObject is destroyed and they are ready for garbage collection. However there is no gurantee that the corresponding stub and home stub is also destroyed in the client but if you try to call methods on them you will get java.rmi.NoSuchObjectException(Remote) javax.ejb.NoSuchObjectLocalException
SCJP 5<br />Brainbench Certified in C++<br />PMP<br />Dallas,TX
Yes, you are right. My question is partially answered.
According to the spec, when you call create on the Home stub, it will eventually return a EJB Object stub to you. I would imagine that the Home object on the server creates the EJB object stub and sends it to the client. So why the HFEJB claims that the EJB object stub as well as Home object stub do not exist on the server? They exist at least until they are sent to client.
" EJB object stub as well as Home object stub " are created by the Container so you really not sure wether it kept them alive or not. I guess this is vendor specific. But this two stubs wont relate any way with the bean in the server. So when you call remove, you are removing the bean instance on server side not the stubs.