ejbCreate()

[Prasad Kuppa]

Hi,
can anyone explain what exactly happens when the container calls the ejbCreate() method on a session bean? What I understood is, it links the EJBObject implementation class (that Container generated and has security, transaction, persistence etc. info) with the Bean class (that we wrote). But, how exactly this 'linkage' looks like? Can you specify some pseudo code?
Please correct me if what I understood is incorrect.
Thanks,
Prasad

[Kathy Sierra]

Howdy --
Well, I'm afraid I can't answer it because I don't have inside knowledge of any particular vendor's implementation. Remember that the specification does not really define this process at all... in fact, the lifecycle and OID diagrams are meant to be a *conceptual* picture of how it works, and not, according to the spec, "prescriptive." In other words, the Container doesn't necessarily create the objects in the way that it's shown in the diagrams. The only thing the Container must do is BEHAVE as if that's how it works.
For example, the Container might give each and every client a reference to the SAME remote service, and the stub carries enough information for the service to simply route it to the Container where the Container then lays the services in and invokes (if and when it is appropriate) the bean's method. So, there might not even *be* a real instance representing an EJB object. When the bean calls getEJBObject() on its context, the bean is getting back *something* that implements the EJBObject interface, but you have no idea what or how that implementation exists in the Container.
And of course it will be different depending on whether the bean is stateful or stateless. So the question of what really happens to make that link is not a question that can be answered in the spec-- it can be answered only by a vendor who tells you how they chose to do it. From the Bean Provider's perspective, you have to know that it is guaranteed to BEHAVE in a particular way, as if it DID look just like the pictures in the spec (or in our book, for that matter), with all the objects floating around in the Container just as they are in the pictures, but what is inside the Container might look very, very different.
All I'm concerned with is that I KNOW, for example, that within my ejbCreate() method (for a session bean but NOT an entity bean) I am allowed to call getEJBObject() on my context, and *something* that implements that interface will be returned. And that the EJBObject implementation I get back can be passed to others as part of an argument or return, and that a remote stub (or something that functions as the stub) will be substituted, and that *whatever* that stub is, it can be used to invoke the component interface methods.
So, I did a lousy job of answering your question , but as far as the spec and exam goes, this is all we can ever know about it. If you want more details, you'll have to get vendor-specific info, which of course could (and usually is) wildly different from Container to Container, and even within different versions of the same vendor's product.
cheers,
Kathy

[Joe McIntyre]

Looking at pages 224 through 227, it appears the EJBObject is not "linked" to the stateLESS session bean until a client calls a business method. But then if you look on page 228, it says that in ejbCreate() you can get a reference to "your" EJBObject. Then in the little note to the right, it says it's the container that decides to create the stateLESS bean (for the pool), and that at the point of creation it isn't tied to any client. But it would seem the EJBObject should be tied to a client, since the client has the stub that communicates with that object (page 224). So how can you get a reference to your EJBObject from ejbCreate() when you aren't even associated with a client yet?
Now your question makes more sense for a stateFUL session bean. First of all, a stateFUL session bean services only one client, so it makes sense that you could get a reference to the EJBObject early in its lifecycle. Looking at pages 192 and 193, it seems clear that this is indeed the case. And on page 196 it says that inside ejbCreate() you can get a reference to your EJBObject, and you can get security info about the client.
As for the actual linkage, I can't answer that. Seems like there would just be some standard java fields somewhere (inside SessionContext? EJBObject? Container code?) that do the job.
(Oops... I was in the middle of writing my post, and didn't see Kathy's reply.)
[ November 25, 2003: Message edited by: Wally Flint ]

[Prasad Kuppa]

Thanks Kathy. Thanks Wally.
Prasad

[Kathy Sierra]

Howdy,
Yes, the Container does some special tricks to make it possible for a stateless bean to get a reference to an EJB object in ejbCreate() even though there isn't necessarily an EJB object associated with the client... because there might not even be a client!!
All that matters is that a stateless bean can get a reference to an EJB object that works for that bean type. EJB objects for stateless beans do not have to be associated with any particular client. So imagine that I'm a Container... I can create one EJB object and associate ALL stateless beans of a particular type with that EJB object. ALL clients may have a stub to that same *thing* and that *thing* (which implements the component interface) is simply a part of the Container that decides how to communicate the method call to the bean (this *thing* might even be the part of the Container that layers in all the services for security, transactions, etc.).
For all we know, it might even work that way for stateFUL beans as well... if you are a Container and you're trying to conserve resources, you might have extra 'smarts' in the stub so that all the stubs for a stateful bean type have enough info so that the one single EJB object knows how to locate the correct bean... the bean holding that particular client's conversational state. So even with stateFUL beans, we still don't really know if there is an EJB object dedicated to each client. All we can say is that it BEHAVES that way. What's underneath is still the big mystery.
So one of you out there must be working for a vendor... maybe you can get an example of how a particular vendor does it... but just remember that you are not supposed to KNOW what's happening, and of course it would be really bad if you wrote code depending on a particular implementation. But you knew that I just have to remind you that for the exam, we know only what the spec wants us to know -- even in areas where it doesn't appear to make sense... like how a session bean can use ejbCreate() to get a reference to its EJB object, when the EJB object hasn't necessarily been created (but we now know that at least SOMETHING that implements the component interface must exist by the time a stateless bean is created.) Oh, the joys of the always-clear, always-logical, never-ambiguous spec
cheers,
Kathy

[Joe McIntyre]

Alright sherrif... this time I got ya surrounded.
I'm on chapter 6 (entity bean synchronization). I'm looking at problem 9 answers on page 369, where it says, AND I QUOTE... from within ejbCreate you can invoke getEJBObject on the EntityContext. But page 338 says you can't get a ref to EJB object in ejbCreate. Pages 328 through 330 say the same thing.
Is this just an error?