hi
The container while passivation serializes the state of the bean for a particular client.
when again the client invokes the bean method,activation happens and the state is restored back to it.how does the container identify that the stored state is for that client only,i different client may also have accessed the bean and stored some state.
how exactly does the contianer identify that the stored state is for that client ,and gives the state back to the same client.
thanks in advance
cibi

Hi
State is maintained in EJB per client in different ways.
In case of Entity Bean, pool of instance is made.

State management is used to get maximum efficiency of 'think - time'.

     When client's request's limit exceed this pool size and 'think- time ' facilitate then a particular bean's state is serialized. This serialized state is associated with hash-code of Primary Key.

From context, primary-key can be obtained and using equals() , it find out which serialized state correspond to which primary key.

Remember that primary - key correspond to particular record.

Viren Jasani

Hi
State is maintained in EJB per client in different ways.
In case of Entity Bean, pool of instance is made.

State management is used to get maximum efficiency of 'think - time'.

     When client's request's limit exceed this pool size and 'think- time ' facilitate then a particular bean's state is serialized. This serialized state is associated with hash-code of Primary Key.

        From context, primary-key can be obtained and using 'equals()' , it find out which serialized state correspond to which primary key.

In case of SessionBean, State is serialized for a particular client and later it can be retrieved for that client's Id.

Hope it will help you.
Viren Jasani
viren_jasani at hotmail dot com.

cibi,
If you were referring to session beans, remember that only statefull session beans hold any type of client state. These beans cannot be used by multiple clients: each statefull session bean only serves one individual client. So it's impossible that a different client accessed the data.

Viri,
"When client's request's limit exceed this pool size and 'think- time ' facilitate then a particular bean's state is serialized."
This is incorrect. I assume you are referring to entity beans here (because stateful session beans do not have a pool, and stateless beans are not serialized). An entity bean need not be serialized. The container can make it store it's state in the DB and then passivate it. Serializing the entity bean doesn't make any sense.
Another thing, the entity bean instance for a particular request is not allways looked up based solely on the PK. This is true only in commit option A. In other commit options, the caller transaction also plays a role.

Gal