I have a stateful session bean implementing remote interface.
It is deployed on one instance of TOMEE. ( I packaged EJB implementation as a JAR and put in WEB-INF/lib folder of a web application and deployed it on TOMEE).
On another instance of TOMEE, I created a client application. In the servlet init() method, I am looking up that stateful bean.
Invocation is successful.
Now, I change implementation of the stateful bean, rebuild the JAR and redeploy.
I also restart the server on which client application is deployed so that it looks up the new stateful bean.
But to my surprise, the old bean is retained on the server (as I can see from the print statements).
My question is, does stateful bean remain in container cache even if the container is restarted? What if I want a new implementation? Will it remain till the cache duration?
My question is, does stateful bean remain in container cache even if the container is restarted?
Generally spoken: no they don't survive a restart, however it is possible (as you have noticed)
This is what the specs say about it:
Chapter 3 Client View of a Session Bean Each session object has an identity which, in general, does not survive a crash and restart of the container, although a high-end container implementation can mask container and server crashes to a remote or web service client.
What if I want a new implementation? Will it remain till the cache duration?
A stateful session bean is removed under three conditions:
- a System Exception is thrown from a beans method
- a time-out occurs (mostly when the client doesn't do anything anymore)
- the remove() method is called on the instance
I am pretty sure when you undeploy the application the container will remove the Stateful Session Beans and its cache. (note that an undeploy is different from stopping and starting the server)
When I undeployed the application and cleaned up server directory, the bean was removed.
Further to this, I assume that a remote client should be deployed on the same application server type on which the EJB implementation is deployed. (In my case, TOMEE) since the provider URL, context factory etc. are app server specific.
If the client is deployed on other server type, then probably web service is the choice to be made.