aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Getting EJBObject for SLSB in ejbCreate() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Getting EJBObject for SLSB in ejbCreate()" Watch "Getting EJBObject for SLSB in ejbCreate()" New topic
Author

Getting EJBObject for SLSB in ejbCreate()

Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2851
    
  11

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
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2851
    
  11

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
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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
Sheriff

Joined: Oct 01, 2001
Posts: 2851
    
  11

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
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Getting EJBObject for SLSB in ejbCreate()