I passed the SCBCD-exam, using "Head First EJB" book of Cathy. I am now working on the SCEA-exam using the SCEA for J2EE technology of Mark Cade. From the Cathy's book I understood that statefull session beans are not pooled. However from the Cade book I understand they are! Passivation is actually writing the conversational state to a file, so the bean can be used for other clients.So the concept of pooling applies also for statefull session beans. Anyone else has an opinion on this?
On pg 21 of Cade's book under Passivation section, it says it's only available with entity and stateful session beans. Resource management: Entity bean -- passsivation, pooling Stateful session bean -- passivation Stateless session bean -- pooling
From the Cathy's book I understood that statefull session beans are not pooled. However from the Cade book I understand they are!
Could you please point out the pg on Cade book? Joyce [ May 09, 2004: Message edited by: Joyce Lee ]
Joined: Jan 20, 2004
Hi Joyce, Thanks for your quick response.
Could you please point out the pg on Cade book?
You already mentioned page 21. Under the header "2.11 Passivation of EJB", passivation is defined as "the process of writing the bean's state to a file on the file system, so the instance of the bean can be used by another session." and last line of the paragraph:".. when the bean passivation session returns, the bean is activated and the bean is state is reloaded into an instance of the bean". Obviously there is reuse of a statefull session bean, although before reuse the state is removed and stored on the filesystem. It makes to me sense. You remove the "statefullness" of the bean, and then you can use it like you use the stateless beans, like pooling it. But maybe I got this concept wrong and it is not technically done this way.
Hi Joyce, Thank you for your research! I read the links you presented. I also looked in the EJB 2.0 specs. I tend to conclude that what Cade suggested could be the case in a container,meaning that after passivating a statefull session bean, the instance is stripped from his conversational state and that the instance can be used by other session. However it does not seem to be specified in the EJB 2.0 specs. And maybe their ain't no container actually using this construction. (Are there container-vendors reading, who can verify this? ;-) ) If this construction would be used in a container, there is however a clear difference in the nature of the pool, compared to the pool of "stateless session beans". In the "stateless" pool the instances are "method ready". In case of a pool of "stripped" statefull beans, the beans are clearly not method-ready as a "conversational state" has to be loaded. The discussion seems to go into the realm of the container-maker, so probably not that interesting for developers. Thanks again for your quick responses! Regards. Cor [ May 09, 2004: Message edited by: Cor Lieftink ]
Joined: Jan 20, 2004
Hi Joyce and others,
In IBM Websphere Application server, stateful session beans are pooled as described earlier!
As I continue my journey in J2EE with working now for the IBM test 287 Certificate "Developing J2EE Applications with IBM Websphere Studio", it turned out that IBM Websphere exactly works with pooling statefull session beans by stripping off (passivating) the state , keeping the instance in a pool and when put in active service , adding the state to an instance out of the pool.
From the study-guide (1):
Websphere will manage a pool of stateful instances, passivating and then activating them as necessary to serve client requests, in effect, "switching" the client's state in and out of instances as required by requests.
and a few lines further down:
Why passivate? Passivation allow Websphere to manage a small pool of available instances. It can switch the state for many clients in and out of just a few real stateful instances. This is much more efficient use of resources than maintaining an instance for every previous client.
(1) Kushner, H. (2003) "Developing J2EE Applications with IBM Websphere Studio" IBM Press, page 146 [ June 25, 2004: Message edited by: Cor Lieftink ]