Getting EJBObject for SLSB in ejbCreate()

[Greg Charles]

One of the hardest things for me to memorize for this exam is what operations can be called from where for which type of bean ... partly because there are a lot of different cases and partly because they often makes no sense.

The case in point: ejbCreate() for a stateless session bean. Now we know that this can be called long before there are any clients, as the container builds a pool of the beans. How is it then that we can call getEJBObject() on the session context during ejbCreate? There is no EJBObject until a client calls create() on the home interface! The lifecycle shown [ UD: removed link to copyrighted material ] agrees with me, as does the lifecycle from HFEJB. So what is that call returning, and what could you possibly do with it?
[ August 03, 2007: Message edited by: Ulf Dittmer ]

[Roger Chung-Wee]

What you describe is the perspective from the client point if view. But because the EJB spec mandates that a reference to the EJBObject associated with an instance of a session bean or entity bean must be returned from the SessionContext and EntityContext respectively, the container will return that reference. It doesn't matter whether it's a reference to the real EJBObject or something that looks like the EJBObject: what matters is that the container meets the requirement of the spec.

[Greg Charles]

That somewhat begs the question. For stateless session beans, an EJBObject is created when a client calls create() on the home interface. Later when the client calls a business method, the container pulls a bean instance out the pool and associates it with this EJBObject. The EJBObject lives until the client calls one of the remove() methods. No doubt the container can create a fake EJBObject to return from a context.getEJBObject() call during the ejbCreate(), but why? In other words, yes, the container must follow the spec, but why is the spec written that way?

[Roger Chung-Wee]

For stateless session beans, an EJBObject is created when a client calls create() on the home interface.

No, you still haven't got it. It looks to the client as if the EJBOject has been created, but this isn't necessarily true. For instance, JBoss has only one physical EJBObject that serves all logical EJBObjects. What the client gets is something that looks and feels like a real EJBObject, but this is merely an illusion.

The EJBObject lives until the client calls one of the remove() methods.

This is not true for SLSBs. Such a call is meaningless as it's the container which decides if and when an instance should be removed from the pool.

No doubt the container can create a fake EJBObject to return from a context.getEJBObject() call during the ejbCreate(), but why? In other words, yes, the container must follow the spec, but why is the spec written that way?

It's possible that the developer may need to obtain the EJBObject reference in ejbCreate, so the spec requires the EJB containers to enable this.

[Greg Charles]

Well, that's an interesting point about JBoss if it's true. It does go against the life cycle diagram shown in the link I provided, and in HFEJB, and basically everywhere else.

In your second point, you've mixed up EJBObjects and bean instances. The container does indeed decide when bean instances will be removed from the pool, and calls ejbRemove() in this case. The EJBObjects are not in the pool. The remove() method is not completely meaningless, since it does invalidate the client's stub, whatever else it may do. It is somewhat confusing though, so don't feel too bad.

I would be willing to concede your third point if you could envision a scenario where a pseudo-EJBObject, which isn't connected with a client and really shouldn't even yet be in existence, would be useful to a bean developer during ejbCreate(). I sure can't, and I haven't seen any discussion of why this might be useful.

[Roger Chung-Wee]

In your second point, you've mixed up EJBObjects and bean instances. The container does indeed decide when bean instances will be removed from the pool, and calls ejbRemove() in this case. The EJBObjects are not in the pool.

True. However, I'd like to pick up what you said about the EJBObject living on until the client calls remove(). I'll stress again that this is how the client sees it as per the OID, but the container is not mandated to destroy this object at all!

Really, it only makes sense for a client to call remove() for stateful session beans and entity beans.

I would be willing to concede your third point if you could envision a scenario where a pseudo-EJBObject, which isn't connected with a client and really shouldn't even yet be in existence, would be useful to a bean developer during ejbCreate(). I sure can't, and I haven't seen any discussion of why this might be useful.

You mustn't look to any scenario which I can envisage, what matters for the exam is what the EJB spec says. And the spec mandates that, for the methods of a stateless session bean, the following SessionContext methods can be invoked from ejbCreate:

getEJBHome, getEJBLocalHome, getEJBObject, getEJBLocalObject.