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!)