File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Understanding the Pooled State in Entity Bean Life 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 "Understanding the Pooled State in Entity Bean Life " Watch "Understanding the Pooled State in Entity Bean Life " New topic

Understanding the Pooled State in Entity Bean Life

Alibabra Sanjie
Ranch Hand

Joined: Feb 09, 2004
Posts: 147
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
Ranch Hand

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

SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
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 ]

Reid - SCJP2 (April 2002)
Alibabra Sanjie
Ranch Hand

Joined: Feb 09, 2004
Posts: 147
Thanks, Reid M. Pinchback!
I agree. Here's the link:
subject: Understanding the Pooled State in Entity Bean Life
It's not a secret anymore!