In an Entity Bean, if a finder method returns a large number of records (say thousands of them), will thousand bean instances be created? If yes, what happens if the number of bean instances required to be created exceed the number of instances which have been specified to be maintained in the pool?
I know this question would have been asked many times in many forums, but I haven't been able to get a convincing reply. Can anyone answer me?
Not only would 1000 beans be created, but since finders return primary keys, 1000 calls to the database would be made (this may not happen with CMP)
I believe that the number of instances in the pool is usually used for session beans, not entities. The app server stores a pool of them to service requests that can be re-used. For Entity Beans, one bean would be created for each "entity" (usually a row in the database).
I don't understand why you think 1000 calls to the DB would be made or a 1000 Entity EJB's would be created.
Finder methods are serviced by Entity Beans that are in the the containers Entity Bean Pool. One SQL call would be made to return the collection of 1000 primary key objects.
As for the loading of the complete persitent state? From the EJB2.0 spec,
"When the container needs to synchronize the state of an enterprise bean instance with the
entity object’s persistent state, the container calls the ejbLoad() method."
It is therefore up to the container when to load the persistent state into an instance Entity EJB. Most containers will not do this unless you specifically call a method on the Entity EJB. If you went down the entire collection accessing each EJB then they would all get loaded.
As per as the EJB2.0 spec , most of the leading App Server will not create 1000 instance at a time . It will be created only when a call is made to that instance .
If i consider that , you will loop thru all the beans
then answer of your question depends on the App server yopu are using . Some application server may increase the no of instance dynamically .
Some may throw exception. This should be very rare case . because other entity bean instances may be passivated ( if no other client using the same ) . But if you are calling methods of all entity beans in same transactional context , then none of the instance can be passivated . So the App Server that does not increase the no of instance dynamically will throw exception
The point is that it does NOT do what would normally be done in a fat-client DB app, which is to make ONE call that returns all the data and possibly use cursors or something to step through a smaller subset of the data when reading.
Also, the point is that the limit on the number of bean instances has to do with session beans NOT entity beans. If you want to access 1000 entity beans and hold simultaneous references to them you can.