Entity Bean instances when mapped to a database table

[Raj Jindal]

I have an entity bean mapped to a database table. There are 1000 records in the database table. If i select all the records using SELECT * FROM TABLE. How many instances of the entity bean will exist ? Will there be 1000 instances of the entity bean in memory ? I just want to know what will be the representaion of the records in memory for my Query ?

Thanks...!!!

[Valentin Tanase]

No that's not the case. The container maintains a free pool of entity beans when it initializes. The pool can grow or shrink, as the container needs to improve the performances or to preserve its internal resources. In order to serve an ejbFinder() method, the container will use an instance from the pool and won�t create any additional instances after or before the finder returns. So it doesn�t matter whether your select query returns 1000 records or no records at all. The container will only return a collection of primary keys that match the records in your database.

[Raj Jindal]

That's fine that the container will return the collection of primary keys correspondingto the SQL query. What will be the internal representation of records in the memory. When i need some record Will i need to use ejbFind() method again.

[kri shan]

I am not understanding this statement 'collection of primary keys' ???

[Valentin Tanase]

I am not understanding this statement 'collection of primary keys' ???

Hi Kri,

Please read it as a collection of remote interfaces.

What will be the internal representation of records in the memory. When i need some record Will i need to use ejbFind() method again.

It might be no record representation in memory, after the finder runs. Here there are my thoughts: entity EJBs won�t leave the pooled state after a finder. The finder only returns a list of remote interfaces to the client. In a way a found bean follows the same protocol as a passivated bean; it is activated when the client invokes a business method on that bean. My point is that after the finder runs I don�t expect much memory allocation or re-allocation to happen within the container. Does the container feel that it needs more bean instances in the pool? That�s fine though, the container will create more instances. The point is that a bean instance is a lightweight component and it doesn�t waste resources (sockets, memory, connections, etc). However if the client loops through all remote interfaces returned by the finder and invokes business methods, then the story will drastically change. The container has no choice but to activate all those bean instances; did the finder returned 1000 beans? Then the container will instantiate 1000 heavyweight bean objects and memory will be consumed, sockets will be used, locking will be acquired, etc. After this point you might think that your records are represented in memory exactly as a set of 1000 EJB objects. Well this might or might not be true, because while the client is looping through all the 1000 beans invoking business methods, the container might decide to passivate some of them. However if you enlist your looping within a transaction then guaranteed you�ll have 1000 beans in memory.