Originally posted by Stefan Peuskens:
In the HF Book is said that during the ejbCreate method of a stateless sessionbean the getEjbObject method can be called. How is this possible.
Isn't it so that the beans are created by the container and put in a pool and that the ejbobject is only created when a client comes by.
When a client invokes create() on the SLSB home interface, the Container first creates an EJBObject, a stub to it and returns the stub to the client. The container creates session bean instances independently from the client's create() invocation, but from the client perspective, when it calls create(), and EJBObject should be available. I suspect that when the container invokes ejbCreate(), it had already created an EJBObject for each bean instance (maybe by maintaning also a 'pool' of EJBObjects?) and therefore the EJBObject is available from the ejbCreate() method. Shouldn't an EJBObject be available when the container creates a SLSB, it will certainly create one at that point. The way each container maintains its EJBObjects I believe is container specific. Let's think at findByPrimaryKey() for entity beans: when the client invokes this method, it receives the bean component interface reference(EJBObject stub, if the client was remote). The steps are:
1) The client invokes findByPrimaryKey() on the home interface;
2) The container asks a BEAN IN THE POOL to check whether the entity for the PK exists
3) The bean, FROM WITHIN THE POOL, checks if the entity exists. Let's say it does, it informs the container that the entity exists
4) The container creates, IF IT'S NOT ALREADY THERE, an EJBObject, a stub and pass the stub back to the client
As you can see from point 4, the EJBObject can be already there or not. How does the container keep EJBObjects on the active heap? Who knows? The point is that there could be already EJBObjects, and the same I suspect is valid for Session beans.