getEJBObject available in ejbcreate for stateles session bean

[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.
Please clarify

[Olivier Dumont]

Hi Stefan,

Welcome to JavaRanch and this forum!

What you described is confirmed by section 7.8.2 (pgs 89-90) of the EJB specs, meaning that the EJBObject (its method "interceptor") is associated with the bean instance in ejbCreate() already.

But what the client receives from a call to create() on the home stub is *not* the EBjObject itself afterall, just a stub given access to *some* EJBObject.

So I don't think there is a real contradiction there.

Regards,

Olivier.
[ August 25, 2004: Message edited by: Olivier Dumont ]

[Kathy Sierra]

This is a strange one that almost *everyone* asks about... remember that any EJBObject for a stateLESS bean is going to be the same for any other stateLESS bean of that type, so the spec really says to a Container vendor: "you must provide SOMETHING to the bean, during the bean's ejbCreate() method, that implements the component interface for that bean type." It does not matter whether that's the *same* EJBObject reference that a client uses at runtime, because there is no specific identify info within the EJBObject for a stateLESS bean.

But yes, it does *look* like a contradiction... how can the bean get a reference to the EJBObject, when the EJBObject doesn't show up on the lifecycle diagrams until *after* a client makes a request? But the spec just tells the Container vendor--"we do not care how you make that work, just do it. Just give the bean *something* that it can use as a reference to something that implements the component interface."

The fact that you spotted this apparent contradiction is a good sign that you are paying close attention to the EJB lifecycles. Good job!

cheers,
Kathy

[alzamabar]

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.
Please clarify

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.

[Stefan Peuskens]

Thanks for the swift replies.