This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming 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 ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

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.
Think of how stupid the average person is. And how half of them are stupider than that. But who reads this tiny ad?
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!