Confused reg. a passage in Ed Roman's Book

[Rahul Roy]

This is a paragraph taken from Mastering EJB 2 - ED Roman
This is reg. Stateful Session Bean.
" To limit the number of stateful session bean instances in memory,the container can swap out the stateful session bean,saving it's conversational state into a hard disk or staorage.This is called passivation.After passivating a stateful session bean,the converstaional state is safely stored away,allowing resources like memory to be reclaimed.When a original client invokes a method,passivated conversional state is swaped into a bean.This is called activation.The client now resumes it's converstaion with the client.Note that the bean that receives the conversational state may not be the original bean.But that's all right because the new instance resumes it's conversation from the point where the original instance was passivated.Thus the EJB does indeed support the effect of pooling stateful session bean.Only a few instances can be in memory when there are actually many client."
Explain me what does the paragraph tell.
now assume that I have 3 client C1,C2,C3 associated with bean instances B1,B2,B3.
I make two assumptions.
1) If all the 3 client are idle and so 3 bean instances B1,B2,B3 and all r in serialized state.One if a client C2 becomes alive and call a business method,from the pasage does it mean that container can take any of the bean instances(it is just a instance no beaness is with it as it is in serialized state) B1,B2,B3 and give the conversational state of client of C2 into bean say B1???
2)Also if 3 bean instances B1,B2,B3 and all r in serialized state and when a new client comes say C4,then any of the bean instances(it is just a instance no beaness is with it as it is in serialized state) B1,B2,B3 will be used for the client C4 and not a new bean instance B4 wud be created for the him/her...
Pls correct .. are the bean instances ( just object no beaness) will be reused in stateful session bean...just like in entity bean where a bean instance comes out of pool and get loaded with the data from database..
[ February 17, 2004: Message edited by: Rahul Roy ]
[ February 17, 2004: Message edited by: Rahul Roy ]

[Jack Zhou]

a stateful sessino bean is tied to a client, period. So the meaning of "not the oringal bean" does not matter, as long as it has the same states as it the bean never been passivated. For me, it certainly it can grab another avaible bean in the pool and updates its stated from the disk. It is the states of the oringal bean stored away. It does not neccessary imply that the original bean is seriliazed. Say C1, C2 are idle and there assoiated seesion bean has benn stored away, at this point suppose there are client c3, c4 request a session beans to work with. Container can simply reuse the two passicated bean to serve c3, c4 with the session bean state cleard. Now if C1 start to talk again, container has instantiate a new sessin bean and copy the state from dis to it to serve c1.
Hope it help,

[Rahul Roy]

Hi Jack,Thanks for your reply.
So from your answer it am getting that instance swapping is possible for SFSB.
In HFE book for enitity beans they have explicitly told that instance swapping takes place..but for Stateful session bean they haven't told about the instance swapping...why???
[ February 17, 2004: Message edited by: Rahul Roy ]

[Kishore Dandu]

could be that author thought it will be too much to dwell a lot into the actual implementation details of the swapping in and out of a SFSB.
Dan.

[Roger Chung-Wee]

This is my understanding.
Method-ready instance pooling is set up by the container for stateless session beans and for entitity beans. This makes sense as any instance will do for a client.
But a stateful session bean is tied to a client. The bean instance is created upon invocation of create() by a client. The container may passivate a bean instance, but will activate it if the client makes a call on it. Note that the container may only remove a passivated instance if its deployer-specified timeout period has elapsed.
Now, the container may do something behind the scenes to make this an efficient process, perhaps by doing something that looks like pooling. But for the exam, we must think in terms of one stateful session bean instance per client.