Stateful session beans Pooling - HFE

[Anand Edwin]

Hi,
I'm confused about the concept of pooling of stateful session beans. It obvious to me that the bean itself cannot be pooled (like stateless beans) because of the conversaional state. However can the bean instance be pooled after the bean(state) is passivated ? (like entity beans) This wudnt really change the lifecycle...
I'm preparing for the SCBCD from Head first EJB and its says that stateful session beans cannot be pooled. Is this because of
the discrepancy in the terminology for 'pooled' (resuse, identical etc) ... would it be more like they are cached ?
OR
is this omitted because its vendor specific?
Best Regard
Anand

Best Regards
Anand

[Brian Smith]

Hi Anand,
like you mentioned, a stateful bean is associated with a client, it can't be sent to the pool like stateless session bean or entity bean. it there is no activity between stateful session bean and a client, then after certain time, the container passivates it to conserve the resources it is taking. When the container passivates, it essentially serializes it and stores in a database just in case a client wants it at a later time.
hope this helps.
namaste.

[Chris Lewold]

I have the same question as the original poster, but I still don't get it.
Yes I know - the bean is associated with a given client, and of course at the time the client uses the bean no other can. But what if the client could "release" the bean - then it could be returned to the pool, and so reused.
Maybe I can answer it myself - I am just not sure:
Answer: There is no "release" to EJBs because this would make the Java "garbage collection idea" obsolete. Consequently there is no "point in time" where the SessionBean knows that the client no longer needs him. -> So he never knows when to return to the pool.
Is that correct?
But .... couldnt "release" be called in finalize() of the Stub ??? I know it's not relieable when finalize is called - but IF it is called it is 100% sure the client no longer needs the stateful session bean .... and then it could be returned to the pool ......
I know finalize should be used mainly to clean up handles to external resources and such stuff ..... hmmm .... wouldn't a Stateful session bean fit into that category ?
Above brought me to the next question:
Assume the client closes. When is the SessionBean actually garbage collected??? How does it know the client no longer needs it ?
And couldnt be THIS exactly the time to return into the pool ?
Just thinking, ....
Chris Lewold
[ January 12, 2004: Message edited by: Chris Lewold ]

[Jacky Chow]

hi Chris,

Originally posted by Chris Lewold:

But .... couldnt "release" be called in finalize() of the Stub ??? I know it's not relieable when finalize is called - but IF it is called it is 100% sure the client no longer needs the stateful session bean .... and then it could be returned to the pool ......
I know finalize should be used mainly to clean up handles to external resources and such stuff ..... hmmm .... wouldn't a Stateful session bean fit into that category ?

In my understanding, I don't think we can use an object again after it's finalize() method is called by GC !

Originally posted by Chris Lewold:
Assume the client closes. When is the SessionBean actually garbage collected??? How does it know the client no longer needs it ?

Container does not know the client is closed if the client does not tell him, the bean instances is removed after a TIMEOUT, you may see EJB spec page 77 to get more about this.
I also do not know why there are no pool for stateful beans, I think pool should be used, can anyone help us ?

[Keith Rosenfield]

The reason stateless session beans can be pooled is that they are on equal footing. Any bean can be pulled from the pool to service a client request. There is no requirement in the spec that a container must pool stateless session beans but pooling helps performance because the beans are created ahead of time. When a client needs one, the container has one ready to go instead of having to take the time to create one.
I think the reason why stateful session beans are not pooled has to do with how they are created. When they are created the state of the bean is set by calling the appropriate create method and the bean is associated with a particular client. If the beans were pooled, there would not be an opportunity for its state to be set and an association made. I hope that Kathy can confirm or deny this.
[ January 12, 2004: Message edited by: Keith Rosenfield ]
[ January 12, 2004: Message edited by: Keith Rosenfield ]
[ January 12, 2004: Message edited by: Keith Rosenfield ]

[Jacky Chow]

I still think that stateful beans can be pooled even some states may be set by create(...) and ejbCreate(...), pooling can be done after ejbRemove() is called, the container can clear the states of the bean instance and put it in to a pool. After pooled, if a client needs a bean with client specific states(provided as parameters of create method), then the container can choose a bean instance from the pool, and set the instance's states to the specific states!
I am not sure if the above scenario does not work! any help?

[Keith Rosenfield]

I suppose it is possible for a particular container to use pooling for stateful session beans. It's just not required by the spec.

[Philippe Maquet]

I fully agree with Keith. Till setSessionContext() (constructor + setSessionContext()), the caller doesn't really comes into the game. So we could imagine a given container precreating a bunch of stateful session beans, just to serve new clients a little quicklier.
But it would be 1) vendor specific / 2) quite different from stateless session beans pooling.
So I'd rather call that "instances caching" rather than "instances pooling".
Best,
Phil.

[Sudhir V]

I think the overhead involved in with/without pool is the same. If a pool is used and stateful beans are pooled between method calls then there will be additional code required in the ejbPassivate and ejbActivate to save/reload the state. Also there is overhead involved in the organization of the pool and it morever makes it more complex. The idea of 1client 1bean just makes the process less complex.