• 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
  • Bear Bibeault
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • salvin francis
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
  • Jj Roberts
  • Carey Brown
  • Scott Selikoff

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.
Who among you feels worthy enough to be my best friend? Test 1 is to read this tiny ad:
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic