ejbFind question

[D. Rose]

I have a doubt about ejbFind method. Monson book states following for ejbFind in entity beans

Topic-Transitioning from pooled state to ready state via a query method
In many cases ( depending on EJB vendor) found entity beans don't actually migrate to ready state until they are accessed by client. So for example if a find method returns collection of entity beans,the entity beans may not be activated until they are obtained from collection or accessed directly by client. Resources are saved by activating entity beans lazily(as needed)

I have following questions-
When a finder method already does a read from DB and creates bean instances and returns EjbObject to client, isn't that EjbObect associated with bean instance already so why not move it to ready state? So what is the use of activating it again ( and doing ejbLoad)? How resources can be saved?
Can anybody shed some light on this?

[Vishwa Kumba]

This is an interesting question.
IMO, the collection returned contains a list of EJBObject references and they are not related to any bean instance
in the container at this point.
When the client actually tries to access a business method with one of the EJBObject references,
then a bean is pooled out from the pool or created new if none exists in the pool, and associated with this
EJBObject and placed in the ready state, so that the business method can be executed.
This is just a flexibility that the EJB Spec provides.So it is entirely upto the vendor, how he implements it.
So in general, we can assume that the finder methods are always executed by beans in the pool and they
never transition out of the pool, unless a business method is called.

[Vishwa Kumba]

When a finder method already does a read from DB and creates bean instances and returns EjbObject to client, isn't that EjbObect associated with bean instance already so why not move it to ready state?
- I think finder methods are executed for beans in the pooled state, and for beans in the pooled state, there is no EJBObject. In the pooled state, the beans do not have an identity. All beans of the same type are the same.
So what is the use of activating it again (and doing ejbLoad)? How resources can be saved?
- Usually the finder methods returns a set of rows. For example:
the collection returned, could contain 10 EJBObject references, all associated with 10 different rows.
The bean instances are not created or retrieved from the existing set of beans in the pool state, unless a business method is actually called on these EJBObject references. In this way, resources are conserved.(Lazy loading). When a business method is actually called, the container tries to associate the EJBObject with a bean and then, synchronize the bean's state with the row present in the database by calling ejbLoad.
[ March 15, 2004: Message edited by: Vish Kumar ]

[D. Rose]

Hi Vish,
Thanks for answering in detail. So you mean to say that when database read is done using an instance in bean pool, only EjbObject is created and no corresponding bean instance?
Does the container do a second database read when actual ejbLoad occurs on activation?
Isn' it costly to go to database twice for same info? Or is it that data row info is cached somewhere on first read(even though bean instance is not created)?

[Vishwa Kumba]

So you mean to say that when database read is done using an instance in bean pool, only EjbObject is created and no corresponding bean instance?

.
- Yes.(that is how resources are conserved, the less bean instances
the better for the server)

Does the container do a second database read when actual ejbLoad occurs on activation?Isn' it costly to go to database twice for same info? Or is it that data row info is cached somewhere on first read(even though bean instance is not created)?

- Yes, the container does a second database read thru ejbLoad(), when the client calls a business method. Note that this is the bean instance in the collection and may be related to a different table/row in the database.
The spec does not say anything about caching, but caching happens to be one of the marketing flings for EJB, especially the CMP part.It is quite vendor specific and may/may not be present in an app server.