Understanding the Pooled State in Entity Bean Life

[Alibabra Sanjie]

In the spec, it said:

The container is NOT REQUIRED to maintain a pool of instances in the pooled state. The pooling approach is an example of a possible implementation.

My question is that if the container provider not implementing the pooling approach, that means no entity bean instances pool, and how do I understand the pooled state in the entity bean lifecycle? There will be no pooled state in this scenario since there is no pool for the entity bean instances, or something else? Any comment will be appreciated!

[Roger Chung-Wee]

Normally, you would expect the container to invoke ejbActivate() when the entity bean instance is taken out of the pool to become associated with a specific EJB object. But if there is no pooling, then I'd say that the container would have to create a new bean instance and invoke its ejbCreate() method.
Or to put it another way, you would expect either ejbActivate() or ejbCreate() to be invoked.
Corrections, please, if I've got this wrong ...

[Reid M. Pinchback]

The state diagram shown for the entity bean lifecycle in the spec and HFE might be well-intentioned but sometimes it borders on mis-information. It is very important to think of the diagram as a conceptual model and highly summarized, not a practical and detailed state transition model. One of these days I'm going to sit down and wade through each point of the spec and draw out the real one, because the 'official' one isn't much use.
To the spec 'in the pool' simply means that there is a state, however it is implemented, where the server can use the logic in your bean class to service home methods. Instances that have been bound to specific entities are definitely not 'in the pool'; their entity-specific state bars such instances from being any help to the container in servicing home methods. Unlike with stateful session beans, in entity beans ejbPassivate and ejbActivate are really about moving beans in and out of the pool.
If it helps, think of unpooled instances are being a bit more like stateful beans because they have to service a specific need (client-specific data for a stateful bean, a specific entity's data for a stateful bean). Pooled instances are a bit like stateless beans because anything in the pool (for a given entity home) can service a home method.
I found something interesting in the spec yesterday, and I have to see if I can find the corresponding coverage in HFE. My recollection was that in HFE an entity bean instance couldn't be passivated if it was in use in some transaction. It is possible I'm mis-remembering the HFE material, but the spec definitely, very specifically says that an entity bean can be moved to the pool during a transaction.
So, getting back to your original question, in a completely insane implementation of an entity bean container you could have one bean per home doing *all* the work, with the server shifting into and out of the 'pooled' (i.e. unallocated to a specific entity) state as necessary.
[ February 17, 2004: Message edited by: Reid M. Pinchback ]

[Alibabra Sanjie]

Thanks, Reid M. Pinchback!