Connection Pooling in stateful EJB beans
scott miles
Ranch Hand
Posts: 70
posted 6 years ago
-
1
-
-
-
-
On one of the site i read that stateful session beans are not usually pooled. i doubt this staement.My question here if stateful beans are not pooled there wont be any need for ejb activate and passivate.(because passivate is called when client request some bean and its already engaged.Then it will passivate it Least used bean. Then it means statefulbeans must be using pool concept).Is the above understanding correct stateful bean can also use pooling?
if it uses pool, when client calls remove it must be cleaning its old state Right?
if it uses pool, when client calls remove it must be cleaning its old state Right?
posted 6 years ago
Scott,
So far as I know, stateful session beans are not pooled. Pooling is a technique adopted to solve the serial synchronization issue, in other words, to avoid the problem with multiple access to the same bean which creates synchronization problems and also the serial access which in case of synchronizing the whole bean could make serial requests wait too much.
So, once stateful session beans are guaranteed to be unique by client, they're not usually pooled.
I don't think so, even the implementation being specific by vendor therefore susceptible to any implementaion, the computacional price to clean the state of a bean is much higher and could even though not work properly. Even with stateless session beans the state isn't cleaned across multiple requests.
Conclusion, there is no such thing as pooling for stateful session beans, they're created exclusively for a given client and once the remove method is called they're ready to be collected by the GC.
Hope this helps!
So far as I know, stateful session beans are not pooled. Pooling is a technique adopted to solve the serial synchronization issue, in other words, to avoid the problem with multiple access to the same bean which creates synchronization problems and also the serial access which in case of synchronizing the whole bean could make serial requests wait too much.
So, once stateful session beans are guaranteed to be unique by client, they're not usually pooled.
if it uses pool, when client calls remove it must be cleaning its old state Right?
I don't think so, even the implementation being specific by vendor therefore susceptible to any implementaion, the computacional price to clean the state of a bean is much higher and could even though not work properly. Even with stateless session beans the state isn't cleaned across multiple requests.
Conclusion, there is no such thing as pooling for stateful session beans, they're created exclusively for a given client and once the remove method is called they're ready to be collected by the GC.
Hope this helps!
Feel free to ask me anything!
www.BlackBeltFactory.com/ui#!/ref=jmotta, SCJP 6, OCWCD JEE5, OCE EJB JEE6
scott miles
Ranch Hand
Posts: 70
posted 6 years ago
If stateful session beans are not pooled, then when ejbpassivate and ejbactivate methods are used?
As per my understanding ,when SFSB are pooled and all SFSB are engaged in servicing then say some request comes. Then container tries to passivate the LRU SFSB anf make it available for new request. But i think it is required in case of pooling only.
If SFSB are not pooled is there any need of passivate/activate methods?
As per my understanding ,when SFSB are pooled and all SFSB are engaged in servicing then say some request comes. Then container tries to passivate the LRU SFSB anf make it available for new request. But i think it is required in case of pooling only.
If SFSB are not pooled is there any need of passivate/activate methods?
