what's the state when ejbCreate ...

[Yi Meng]

what's the state when ejbCreate is called for CMP entity bean?
I thought ejbCreate was called when it was in "pooled state", and after ejbCreate and ejbPostCreate finish, the bean is then in method ready state. But according to the answer given in HFE final mock exam q4, it is not.
Can anyone explain something? Also for ejbActivate, ejbPassivate .... Are they called at the state where the bean initially is in? Or are they called OTA(over the air, not in any state)?

[Philippe Maquet]

Hi Yi,
I understand your confusion because I got the same . Such a question plays with words (or we think so ), hence the confusion.
"Which method(s) can be run by a CMP bean in the pooled state ?" (choose all that apply)
A. ejbLoad()
B. ejbFind()
C. ejbStore()
D. ejbCreate()
E. Business method
F. ejbHome()
I missed the question (though the answer given in HF EJB is correct) because I chose B and D while correct answers are B and F.
B is OK and obvious.
D is incorrect, but it shows that I was confused about ejbCreate() as you are.
And I didn't checked F because a method named ejbHome() cannot exist (because it would correspond to some "unnamed" home business method - but where to stop with logic in such a question ?!).
ejbCreate() is a bit confusing because it runs between both states (pooled and method-ready). OOH, like a method run in the pool, the bean has *no ID* in ejbCreate(). OTOH, once ejbCreate() starts, the bean moves out of the pool. Hence my hesitation ... and my bad answer.
Best,
Phil.

[Kathy Sierra]

Yeah, this is a fun one...
The bean STAYS in the pooled state for finders and home business methods. But with ejCreate(), the bean transitions OUT of the pool to the method-ready state.
So, even if the bean is in a state of transition, it still is NOT considered "in the pool".
But it's true that there's no method named "ejbHome()", so we really shouldn't have printed it that way. But we're not trying to trick you. When we say ejbHome or ejbHome(), we're talking about home business methods, and when we say ejbSelect and ejbSelect() we're talking about select methods, even though the *real* method names would have more characters added to the names. But this is the way we refer to them. I can see how this is confusing, though, since as Philippe said, there IS no method with the name ejbHome(). But whenever you see a reference to ejbHome(), just mentally think "ejbHome methods" or "home business methods" or "methods in the home interface which are NOT create or finder methods" or "methods in the bean that start with the characters 'ejbHome'" They all mean the same thing.
Anyway, just remember that if a bean is in a *transition* out of the pool, then the method does NOT run while the bean is "in a pooled state". You must look at the lifecycle/state diagrams to see how these methods are run. But it IS true that ejbCreate() might be *invoked* on a bean that is in the pooled state! But it will not be *run* by a bean in the pooled state, because the *instant* the bean begins to run the ejbCreate() method, the bean is already actively IN the process of *becoming* a specific entity. Things that run in the pooled state are those that don't ever cause the bean to "become" a particular entity.
Think of methods that the bean runs in the pooled state as methods which apply to this bean type as a whole, rather than to one specific entity of that type. An ejbCreate() is definitely about ONE specific entity. A business method is always run on one specific entity. But a home business method (something that starts with ejbHomeXXX()) is something that runs on behalf of many beans... like a batch operation or a query, etc. The tricky one is findByPrimaryKey(), since it's obviously tied to a specific entity. But think of finders as the container's way of saying, "Hey, just VERIFY for me that these things exist in the database". That's it. Whether it's one single one, as in an ejbFindByPrimaryKey or a multi-row, it's still all about doing a query. With a finder, even a SINGLE entity finder, the bean NEVER automatically *becomes* that entity. It just verifies (while still in the pool) that this entity does exist in the database. Just in case the client gets serious and decides to say, YES, I want to call a business method ON that entity I've just found...
cheers,
Kathy
(and thanks again Philippe!)
(and happy birthday again to Keith!)

[Yi Meng]

so how about ejbActivate, ejbPassivate?
shall we say that ejbActivate is called when the bean instance is in pooled state and ejbPassivate is called when the bean instance is in method ready state, but they do NOT run in any state?

[Philippe Maquet]

Hi Yi,
You are right.
Kathy, about the ejbHome(), it's just a naming convention. And the fact your mock exam is written in the same style as the real one is one of the reasons for which your final mock exam is *so* useful. I missed that question, but I remembered "OK, if I read ejbHome() on the real exam, I'll translate in 'home business method'".
Regards,
Phil.

[Kathy Sierra]

Originally posted by Yi Meng:
so how about ejbActivate, ejbPassivate?
shall we say that ejbActivate is called when the bean instance is in pooled state and ejbPassivate is called when the bean instance is in method ready state, but they do NOT run in any state?

Hmmm... yes, I think you could kind of think of it that way.
These methods are called as part of the *transition* from one state to another, but do not specifically RUN under the state in which they're called. So yes, while ejbActivate() is called when the bean is in the pooled state, we do not consider it to RUN while still in the pooled state... it is running as part of the state transition. Same with ejbPassivate.
Really, though, the reason that this question about finders and home business methods matters is just so that the candidate knows for certain that an entity bean can really perform TWO major jobs -- or wear TWO major "hats" -- one as a bean that is pretending to BE somebody, some specific entity (like Fred Smith, #42), and the other as a bean that can act on behalf of ALL entities of that type (like A Customer Bean). So when the bean is in the pool, it is like an actor that is NOT currently playing a specific part/role, but rather an actor just working around the set on behalf of all the actors, doing tasks. But when he comes out of the pool to BE somebody, then he has to play a specific role and everything he does after that (until he goes back to the pool) is on behalf of that ONE specific entity who the bean is currently BEING.
So that's the main reason we emphasize knowing whether the bean comes out of the pool... to emphasize the nature of which role the entity is taking on--BEING a specific entity, or acting on behalf of all entities of that type.
cheers,
Kathy

[Philippe Maquet]

Hi Kathy,
As this thread seems to be dedicated to the entity bean lifecycle (ejbCreate() first, now ejbActivate() / ejbPassivate()), I'd like to check with you my understanding of it.
As the guy on the picture p.320 of Head First EJB says (in other words ), it's terrible to memorize in comparison with the other lifecycles.
First why do we need to learn/know such a lifecycle ? To know :

WHAT happens

WHEN it happens (and in which sequence)

WHAT WE CAN DO (or not) at each stage (access to all or part of the "beanness" power).

I think that point 3 is the most important.
If we come back to the entity lifecycle picture, and if we take the selfish point of view of the Bean Provider (I don't think that any of us will ever develop a Container ), the entity bean lifecycle can be simplified in two ways IMO :

methods that we don't implement by ourself : ejbSelect*() and ejbFind*(). Why the heck do we need to know that ejbFind*() methods and ejbSelect*() methods running in the pool are in a state where the bean has no ID (no EJBObject / no primary key) and that ejbSelect*() methods may run in the ready state ? We don't write them anyway. So let's "overstrike" them on the picture (OK just in our selfish Bean Provider's mind )

Now let's make a big jump 36 pages further in the book (p. 356) and read what we must know about the commit options. As the Container is free to support any of those options, there is no garantee that ejbActivate(), ejbPassivate(), and ejbLoad() (I think there is an exception for ejbStore()) will ever been called. It means that any Bean Provider willing to write entity beans which are portable accross all EJB vendors should *never* use one of these methods, right ? If that's OK, we may overstrike those 3 methods too (still just in our mind of course ).

If we do, we just keep something quite simple to remember, finally :

POOLED = ejbHome*() methods = NO ID (no EJBObject / no primary key)

one "special" transition method : ejbCreate*() (first part of the create process) where you have no ID as in the pooled state

METHOD READY = all other methods = full power

Now for the exam, you *must* know everything about the methods I "overstroke" above of course :
ejbActivate() / ejbPassivate() : no access to transaction
ejbLoad() / ejbStore() : full power (like in ejbPostCreate() or any business method)
ejbFind*() : run only in the pool
ejbSelect*() : run in the pool or in the method-ready state depending on the state in which the calling method was.
Do you agree with all that, Kathy ?
All Best,
Phil.
[ December 30, 2003: Message edited by: Philippe Maquet ]