stateful beans

in a stateful bean ---the container doesn't create a pool. The bean is dedicated to the EJBObject for its entire life(probably why a pool is not created)
But when the bean is passivated the bean is destroyed, and when activated a new bean is created and assigned to the EJBObject.
So why isn't a pool created from which during activation a bean is assigned to the EJBObject instead of creating a new one.

in a stateful bean ---the container doesn't create a pool. The bean is dedicated to the EJBObject for its entire life(probably why a pool is not created)
But when the bean is passivated the bean is destroyed, and when activated a new bean is created and assigned to the EJBObject.
So why isn't a pool created from which during activation a bean is assigned to the EJBObject instead of creating a new one.

Some vendors do choose to implement pooling in the scenario you describe. When people say stateful session beans are not pooled, they are referring to the logical concept (one stateful ejb for one client, do not get pooled).

yes i agree, but i dont understand why in the logical concept also they have differentiated it that way
thks
kiran

Hi Doshi,
Pooling is mainly done to improve the scalability by having a small number of instances servicing many clients.This is true with Stateless and entity beans. The reason that it is not possible with stateful session bean because the bean instance is saved relative to the ejbobject, but it is not like that in entity and stateless session beans. That is why they are put back in the pool and stateful session can't be pooled back or not reusable.
Rgds
Shankar

If that is the case then why would you passivate and then activate again? Once you passivate and serialize all the data, what happens to the bean instance?
I would think that by passivating, we reduce "in memory" data. Is this right?

Hi Chintan,
I was talking about why we are not pooling stateful session bean.
The bean instance is saved in the filesystem but not disassociated from the ejbobject as in the case of entity and stateless and entity beans.In other word the ejbobject is always tied up with the bean instance in the case of stateful session bean.That is why we are not able reuse that bean instance for a different client which is possible with stateless and entity.Hope this makes sense.
Rgds
Shankar

The reason you cannot pool: the container never know about specific information stored in the bean. Imagine a bean like this:
class MyEJB ..... {
private int state = 0;
...
...
}
You can passivate this bean (to reduce RAM consumtion) and activate the bean (if client request it later), but there is no way you can reuse this bean for other client since the state of one client is different to the others. The container just doesn't have a way to modify the state.
Stateless bean won't have this problem since it should never store user-specific information in the bean itself, so it is safe for container to assume the bean is poolable.