Session Bean Pooling

[Meghana Reddy]

Hi all...
Can anyone let me know whether session beans(both stateless and stateful) be pooled???
If yes, how they can be pooled???
and
If no, why they cant b pooled???
Thanks in advance...

[vb reddy]

Yes,Session beans(only stateless session beans) do participate in instance pooling.There is no explicit pooling mechanism as such(atleast for EJBs), but the container does this job for you.
Instance pooling is a technique used by EJB servers to create multiple copies of enterprise beans and then distribute them as needed. It reduces the resources needed at a time.Stateless session beans and entity beans participate in instance pooling. Stateful session beans do not participate in pooling because they maintain the unique state of each client and hence cannot be reused.

[Dharmesh Chheda]

About Stateless session beans:
Because Stateless session bean's ejbCreate() method takes in no parameters,clients never supply any critical information that the bean instances need to startup. The EJB Containers can thus precreate instances of your stateless session beans.When a client calls a method, the container can retrive a instance from the pool, have it service a method, and then return it to the pool
Stateless sessions hold conversations spanning a single method request and are free of client specific state after each method call.All stateless session beans think that they are in the same state after a method call; they are unaware that previous method calls happened. Therefore the container can dynamically reassign beans to the client requests at the per-method call.
About Stateful Session Beans.
When the client invokes a method on a bean, the client is starting a conversation with the bean, and the conversational state stored in the bean must be available for the same clients next method request.To limit the number of stateful session bean instances, the container can swap out a stateful bean saving its conversational state to a hard disk or other storage. This is called passivation. When the original client invokes a method, the passivated conversational state is swapped in to a bean. This is known as activation. The bean can thus resume conversation with the original client.
The container, in case of stateful session beans, may use any algorithm like LRU or whatever to deciede which stateful bean has to be passivated . The algo used varies from container to container.
NOTE: the only time a stateful session bean cannot be passivated is .. if it is involved in some sort of transaction..
so bottom line is that both stateful and stateless session beans can be pooled and the details are as above..and also the conditions ...
i hope this helps
regards
Dharmesh Chheda
[ March 06, 2002: Message edited by: Dharmesh Chheda ]

[Simon Song]

I believe IBM's algorithm for pooling is LRU, unlike WLS can specify NRU/LRU in their DD(though I don't see why it matters).
Instance pooling is meaningful to SLSB.

[vb reddy]

Addressing the current topic pooling means that the container creates a pool of bean instances and use them to serve several clients. Each Bean instance after serving a client will get back to the instance pool(pooled state) and is ready to serve another client. This is what, it happens exactly incase of staleless session beans..
I agree that the container does pasivation and activation of Statefull Session beans during inactivity period to conserve resources. What I am trying to impress here is that, the bean instance is completely evicted from the memory after it is been preserved to a secondary storage(Passivation). Hence there is no issue of,the container using the same bean instance to serve another client. Here each SSB is specific to a particular client and it serves the same old client even after activation..
Hence the summary is that , only SLSB's participate in instance pooling done by the container..
Venu