Win a copy of Fixing your Scrum this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Frits Walraven
  • Himai Minh

an ejb bean pool question

Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Let's go to the waterfront with this tiny ad:
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic