EJB Design

[Rahul JG]

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?

[Byron Estes]

Great question!
I'll give a shot at answering this, but I'd love to hear how more knowledgable members would answer this one.
Here's my take on it...
I'm going to make some comments not to be picky, but to be specific.
The Entity Beans Home Interface has the finder which is used to return remote references that support access to the entity beans themselves.
As I understand it (...and if I'm wrong someone please correct me) there is a pool of objects that implement the EntityBeans Remote interface. These have their own identity and are not associated with a particular Entity Object identity. These pooled remote objects are assigned to an actual entity object at the transition to the READY state. Calling the find method does not move them into the READY state, so you don't need a pool of thousands. If you had an instance for every entity object you wouldn't need pooling, but of course then you wouln't gain it's benefits either. The whole idea of pooling is to service the requests of many with the resources of a few.
Now that being said, the result in your scenario would probably not be very efficient since in order for a small pool of remote objects to service a huge pool of entity objects (...that you would probably process in a loop by a session object) will require the container to thrash in order to swap in and out the entity objects (which requires them to be passivated, synchronized, etc.) as you iterate through the collection.
I think you'd should question whether or not you really wanted or needed to use Entity Beans for something that would return back so many items. You might want to use a Session Bean and some other connectivity API (e.g. JDBC) for this scenario.
Regards,
Byron Estes

[Alexander Yanuar Koentjara]

Hi,
This is my opinion:
Since finder method return Collection or Enumeration object, these classes are provided by vendor, and I don't think it is a default collection classes which we usually use from java.util package (although it uses Collection or Enumeration interface).
The vendor's Collection/Enumeration class is more like a proxy class, and it has smart algorithm not to waste server's RAM by creating 1000 entity beans at one time.
Suppose you create a search engine, and it return 1000 item, will you display them at once? At most case, no, and you will use paging mechanism. And most likely in many case, your code will access one bean (or few) at one time.
So probably, the vendor's self-made Collection or Enumeration object has smart algorithm to handle this, and maybe even you have 1000 bean as result, probably in server side they are just 100 or 50 entity beans relevant to the finder result at one time.

[Mon Mayor]

A simple idea would be to drop some debug code in ejbcreate to see if they are actually created. It would be good to know when the association happens because it already exists and the create is not called explicitly.
Thanks
-MM(scea)

[Emil Kirschner]

Originally posted by Rahul JG:
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?

IMHO: If the pool is big enough and you have enough memory and there is only one active session, I guess it could load everything (unless it uses lazy loading).
But even if the pool is big enough and all the instances would fit in the ammount of memory you have, some of your beans may still be discarded (not loaded) since the container may need to load other beans or it may choose not to discard another bean in order to be able to load yours.
Since you're not accessing your beans all at once, the container can swap it quite nicely. But exactly how all this happens is very implementation dependent.
Keep in mind that in a real world scenario you may have multiple sessions accessing sets of beans in the container. it depends on your app's design, on the user's behavior, on the number of users and mostly on the algorithm the container implements.
Also, consider that the user may interact with your application is a very ramdom way.
Given all these parameters, I don't think it is possible to predict how your beans will be loaded / discarded.
Cheers,
e.

[SPAD]

The returned Enumeration/Collection has the remote references that doesn't neccesarily mean that the corresponding beans have been created. The beans may be in passivated state [no resource usage] and will be activated only in case of business method invocation. Check this out in Monson's book on EJB "The Life Cycle of Entity Bean" on I think page #213 secod ed

[Emil Kirschner]

Originally posted by SPAD:
The returned Enumeration/Collection has the remote references that doesn't neccesarily mean that the corresponding beans have been created. The beans may be in passivated state [no resource usage] and will be activated only in case of business method invocation. Check this out in Monson's book on EJB "The Life Cycle of Entity Bean" on I think page #213 secod ed

I definitely agree. I was talking about what happens on the server side.
e.