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 an ejb bean pool question 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 "an ejb bean pool question" Watch "an ejb bean pool question" New topic

an ejb bean pool question

Jack Zhou
Ranch Hand

Joined: Dec 27, 2003
Posts: 93
ejb 2.0 spec always include pooled state in explaining the life cycle of an ebj. But it also says the following:
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, but it is not the required implementation.
Whether the container uses a pool or not has no bearing on the entity bean coding style

If container does not pool the entity beans, is there still a pool state for each ejb. If not, then the discussions about invoking finder home method on a ejb with "pooled" state will not make sense. And they should be not part of ebj spec. So I assume pooling or not pooling, there is always a "pooled" state in an ejb's life cicle. Am I right?

Thanks,<br />Jack Zhou<br />SCJP, SCJD, SCWCD, SCBCD, SCDJWS,SCEA
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
See related thread
There is an conceptual oddity in EJB; home methods operate on the 'extent' (i.e. over the space of possible entities), component methods operate on specific instances within the extent. The spec is trying to allow room for how the container provider deals with extent-level operations.
It probably would have been better if once-upon-a-time the original EJB spec pulled the two kinds of functionality into different classes, but it didn't. As a result the java code for the extent operations (create, remove, find) lives with the component instance operations. What is a poor server vendor to do? Obvious choice - put some unused instances to work dealing with extent-level activities. Call that 'the pool' and - voila - you have a spec that talks about a pooled state.
An instance pool isn't the only way to deal with the issue. The container implementation could choose to have not just one subclass of your entity bean, they could have two... one for component instance operations, one for extent operations... but that is up to the vendor, and the spec is just trying to make it clear that container vendors are allowed to exercise such options in their implementation.

Reid - SCJP2 (April 2002)
jQuery in Action, 3rd edition
subject: an ejb bean pool question
It's not a secret anymore!