Menu
If the stateful session bean is going to passivate, its state is written to harddisk and then the bean instance will be freed to serve other request (at least this is my understanding). When the same client is active again, bean instance will read the state from hard disk to regain the state. But how the bean instance knows that for which client which file it has to read to maintain the state?
I am very new to J2EE, so please pardon me if I am asking a very naive doubt. If I need to know any other topic to understand this, please point me in the right direction.
423
A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. When the client terminates, its session bean appears to terminate and is no longer associated with the client. The state is retained for the duration of the client/bean session.
Singleton session beans maintain their state between client invocations but are not required to maintain their state across server crashes or shutdowns.
The life cycle of a stateful session bean has three states: Does Not Exist, Method-Ready, and Passivated. This sounds a lot like a stateless session bean, but the Method-Ready state is significantly different from the Method-Ready Pool of stateless beans.
The Lifecycle of a Stateful Session Bean The client initiates the lifecycle by obtaining a reference to a stateful session bean. The container performs any dependency injection and then invokes the method annotated with @PostConstruct, if any. The bean is now ready to have its business methods invoked by the client.
It's best to visualize a Stateful Session Bean (SfSB) as very close to an instance of a normal Java class. You look up (or inject) an instance of a SfSB, and the container will create one for you and return the instance. You then work with that instance like you would any other Java instance.
That means that you can store the instance in to a Session, serialize it to disk, etc.
The detail is that the instance you are working with is actually a proxy to the actual, underlying SfSB instance. It's not the actual SfSB itself.
When you make a call on your local proxy to the bean, it is the containers job to manifest that bean in to memory for you. The passivation and activation of the bean is done behind the scenes for you (though you can tap in to the process through the beans lifecycle).
Any information that the container needs to find the passivated SfSB is stored in the proxy that you're working with, but this is opaque to you. You needn't worry about it.
So, in a typical web based scenario, the life cycle would be that you get your bean instance, store it in a web session, and then simply use it like normal. If the container decides it needs to passivate your bean to make room or whatever, it will passivate it automatically for you. When your user returns, your app pulls the instance from the web session, and makes its calls. At that time, if the bean is passivated, the container will activate the bean for you, again automatically. This entire mechanism is dependent on the container, yet transparent to you. The important thing for you to recall is that you must hang on to SfSB that you get from the container, like you would any java object.
The final caveat is that if you allow a SfSB to be passivated for too long, the container will automatically delete it for you.
120
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
