Win a copy of 97 Things Every Java Programmer Should Know this week in the Java in General 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

an ejb bean pool question

 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • 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
  • 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.
 
This. Exactly this. This is what my therapist has been talking about. And now with a tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic