I want to be clear regarding the bean pooling mechanism. This is what I thing...In my assumptions I use 3 bean instance B1,B2,B3.. Stateless Session Bean: In this the bean is not going to maintan the state of the client... so the container creates and maintains a pool of bean instances say B1,B2,B3,...before the client actually arrives.As and when client calls a method,the container randomly picks a bean from the pool and attach to the EJB Object of the client for the life-time of the method.After the method call is over,the bean is brought back to the pool by the container. Here remove doen't have any effect on the bean. Stateful Session Bean: Here the bean has to maintain the state of the client.So when the client arrives a bean is instantiated.So say there are 3 client now connect to my website and they are actively using my bean.So there wud be 3 instance of bean B1,B2 and B3 attached to the respective EJBObject of clients C1,C2 and C3.Now lets us assume that a new client C4 arrives and due to the limitaion in the resources,container will passivate/serialize one my existing beans(B1,B2,B3).Say it serializes B3.So the sate of B3 is stored in hard-disk.Now my question is will the container instantiate a new instance of bean say B4 or will the existing instance B3 which is passivated will be used???IS the passivation means,the bean state is stored in hard disk and bean instance is there to serve other client???it is confusing for me here..If somebody can help me it will be good. Also what is the effect of calling ejbRemove Entity Bean: Here the container maintains a pool of bean instances B1,B2,B3,..So when client creates or finds a entity row ...that data is fed into the bean instances B1,B2,B3,..After the instance interaction is over,if client C3 using B3 calls remove the data represented by B3 is removed,but the bean instance B3 is in the pool.So if a client comes and aks for a bean B3 is given after attaching his data.. here remove has effect on the data and not on the bean. Here also I have the same question,Will the passivated bean instance B3 be used by other clients.
Stateful Session Bean: ... Now my question is will the container instantiate a new instance of bean say B4 or will the existing instance B3 which is passivated will be used???
The container has to create a new instance B4. The very nature of stateful beans is that B3 probably contains state that only makes sense for the client it is serving.
Also what is the effect of calling ejbRemove
For all beans, probably causes the EJBObject skeleton on the server to be gc'd. What happens just before that depends on the bean type. Stateless beans - remove has no direct impact on bean instances; the server calls ejbRemove when it wants to prep an instance to be gc'd. For stateful beans, the server definitely invokes ejbRemove on the instance and makes it eligable to be gc'd. For entity beans, invokes ejbRemove (and in the case of CMP entity beans, removes the entity data automatically from the persistent store).
Entity Bean: ... Here also I have the same question,Will the passivated bean instance B3 be used by other clients.
Passivation and removal are different things for entity beans. If you have two clients, both holding EJBObject/EJBLocalObject stubs to the same entity bean, only one client uses it at a time - access is transactional. If the first client calls remove() on the bean, the second client will get a NoSuchEntityException. Passivation with entity beans is kind of a wierd beast. I think the Ed Roman book has more detailed coverage on this issue than the HFEJB book. The container may need some bean instances to service the home interface methods, and those beans don't need to be associated with a particular entity. "Passivation" in this case is more like unlinking the association of the bean instance with a particular entity in the persistent store.
Reid - SCJP2 (April 2002)
Reid M. Pinchback
posted 16 years ago
Actually, just thought of something that probably needs clarification. Passivation in the sense of calling ejbPassivate() can happen. An Entity bean instance can have cached state that the container wants out of memory if it decides the bean instance isn't actively being used. The issue of returning bean instances to the pool in order to allow them to be re-used for other entities or to service home methods is achieved by the container invoking unsetEntityContext.
I think if the container invokes unsetEntityContext() the bean moves from the pooled state to Does not exist state
posted 16 years ago
Sorry still I am confused :roll: Why can't after passivation the instance of Stateful session bean be used.. the states are serialized so during activation I can get back the state in the bean instance..It wud increase the performance right???