• 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 ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

Entity Bean lifecycle question...

 
Greenhorn
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)???
 
Sheriff
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.
 
Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic