Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes 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
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

Entity Bean lifecycle question...

Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When the container calls ejbCreate() on an Entity bean, the bean is then considered in Ready State - it is ready to be worked-with, after the new row has been inserted into the DB.
HOWEVER, when container calls a finder method (say ejbFindByPrimaryKey()), it will return the found entity bean instance, but then returns back to the Pooled State...
Why shouldn't the Entity bean remain in Ready state if the finder method returns a single bean instance - AFTERALL, typically when you successfully find a bean instance, you probably are then going to update the DB (via the bean)???
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The following are excerpts from EJB2.0 spec

After the ejbFind<METHOD>(...) method completes, the instance remains in the state. The container may, but is not required to, immediately activate the objects that located by the finder using the transition through the ejbActivate() method.
An instance transitions from the pooled state to the ready state when the container selects that instance to service a client call to an entity object. The container invokes the ejbActivate() method on an instance when an instance needs to be activated to service an invocation on an existing entity object�this occurs because there is no suitable instance in the ready state to service the client�s call.
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.

Clearly pooling is used for optimizing resources. Not immediately creating an entity bean instance soon after executing the finder method is perhaps a strategy for lazy loading. After all, the container cannot assume anything about the duration between client invoking the finder method and subsequently invoking a business method on the instance. If this interval is long enough, and if the container were to immediately activate the entity bean instance, it may be forced to passivate it to conserve memory before the client gets a chance to call the business method.
Remember to always leap before you look. But always take the time to smell the tiny ads:
Garden Master Course kickstarter
    Bookmark Topic Watch Topic
  • New Topic