How many instance of ejb created for a table

[dhanan sekaran]

Hi,
1.I have an entity bean(CMP),mapped to a table with 10 rows, how many instance of a ejb created for that when the container loads. Is it 10 instance created with each instance representing one row?
2.From my servlet iam accessing a entity bean, iam getting reference of home object..., if 10 request comes 10 reference created or from one reference iam acceesing that or what?Please help me.
Regards,
dhana.

[Chris Mathews]

Entity Bean instances can be pooled just like Session Beans. However, the EJB Container must ensure that instances are properly synch'ed up with the database thru the use of the Entity Bean lifecycle methods ejbLoad(), ejbStore(), ejbActivate(), and ejbPassivate(). Therefore, the act of swapping out data in Entity Bean instances is fairly expensive so you want to tune your bean pool size to be a respectable level or, in most cases, let the EJB Container manage the bean pool automatically.
In your example of a table with ten rows, I would think that the EJB Container would create an Entity Bean instance for each row of the ten rows (if you did a find all). There would be no point in swapping instances for such a small number of entities.
I am not exactly sure what you are asking with regards to your second question.

[dhanan sekaran]

Tx Chris,
If i have 10000 rows in a table , container will create 10000 instance of entity bean, each instance representing a row, right?
In my second question , iam accessing a entity bean from my servlet, first i will look up the bean to get reference of home interface, then i get reference of remote interface, then i will do buisness operation, suppose if 1000 request comes to a servlet, 1000 reference for home object created or one reference created and it will be used in each request,
ie) for every request reference of home object will be same and will be created for every request? suggest me.
Thanx,
dhana.

[Dana Hanna]

Originally posted by dhanan sekaran:
If i have 10000 rows in a table , container will create 10000 instance of entity bean, each instance representing a row, right?

Absolutely not. The instances are not based on the rows in the table, just on server load. It might start with 10 instances, and up it as it receives traffic. It may also employ a read-only caching strategy, but this is container dependent.
As for the home reference, you should be caching that in the servletContext...

[Rohit Ahuja]

i strongly contradict the above given explanations.
When we talk of Entity Beans being associated with Database tables,the container cannot associate each instance with a particular row on server startup. The server keeps the bean instances in pooled state ( we specify in our xml files as to how many r the minimum instances that need to be kept in pooled state). These instances once used for a particular row(insert/update), rush back to the pooled state. In a pooled state a bean instance is NOT associated with any particular row. So if u have 10,000 rows and u r firing an update in a for loop, the same bean instance will service all the 10,000 updates in the for loop. However, if u r making updates for different rows from different tables, then diff bean instances will update. But again, the max number of bean instances that will service the requests is specified in xml file. If u start having 10,000 instances, rest assured ur server will come down in no time.
Please feel free to contradict.

[Chris Mathews]

Originally posted by Deepak Acharya:
i strongly contradict the above given explanations.

I never said that the EJB Container does not pool instances. In fact, I explicitly stated that it does. However, in the intitial case I feel that most EJB Containers would indeed create 10 instances. Why not? The overhead of keeping 10 instances in memory is not great and is probably less then the overhead that swapping instances would incur.
If we talk about 10,000 rows then we are probably going to see dramatically different behavior. However, we really don't know enough about how the rows are being accessed. Is it concurrent access? Is it sequential access? Is it a huge finder that returns a Collection of 10,000 Entities? Is it accessing the same exact row 10,000 times?
The actual scenario will definitely affect how the Application Server handles it's bean pool and so will the Entity Bean cache settings. Has the Application Server's pool size been tuned manually, because this could also dramatically affect the behavior. Furthermore, various Application Servers may act in different ways (in fact I guarantee they will).
Basically, what I am getting at is there is not a single "correct" answer that can be given for the question. The question is too vague and there are too many variables in play...

[Dana Hanna]

The point being (seems like a misunderstanding newbie started this), a bean does not exist for every row in the table. If you have 15 rows, and specify a 15 bean minimum, this does not mean that the container will make a bean for each row at load time. If you do a ejbFindAll(), it's quite possible that the container will initialize these beans with the data for each row, but not before that.
If there were 10,000 rows, and did a findAll(), it would recycle/create beans as needed. Regardless - if you are doing a findAll() with 10,000 rows - you need to look at whhy - EJB is not right for this...

[Rohit Ahuja]

Yes, i wud be slightly more comfortable with Danna Hanna's thinking that the bean wud be in pooled state.
Chris, assume i have 10 rows in the table and the minimum pool size i specify is 10. In that case, i was just wondering that the 10 instances will be in pooled state ( sleeping to be picked up by some request ).Only a find method wud link it to a particular row in a particular table. But i still am not quite convinced that the 10 instances wud be linked with the 10 rows. Yes, definately, it will be a time saving mechanism to relate each bean instance with a row in the table. But... (((
Deepak, why are u getting confused. Chris is good i bet.
Chris, do u have something more concrete that will put an end to all my doubts ?? Any more positives of matching a bean instance with a row( assuming only 10 rows in the table ).