Hi, I�m gonna use some situations here to explain: Situation 1 - A servlet that doesn�t implement SingleThreadModel interface and is not marked as distributable in the dd -> Only one instance of that servlet should exist in one virtual machine and the container will create a new Thread to each request that arrive for that servlet to run it�s service method. Situation 2 - A servlet that implements SingleThreadModel interface and is not marked as distributable in the dd -> The container is allowed to create a pool of servlets in one virtual machine and even serialize them to match the condition of only one thread executing per servlet at a time. Situation 3 - A Servlet that does not implement SingleThreadModel interface and is marked as distributable in the dd -> Only one instance of that servlet should exist in each virtual machine that the application is deployed.(This is a tipical clustered environment) Situation 4 - A servlet that implements SingleThreadModel interface and is marked as distributable in the dd -> The container is allowed to create a pool of servlets in each virtual machine. hope this clarify a bit. regards.
But then there's also objective 3.3 "Distinguish the behavour of the following in a distributable: - Servlet context init parameters - Servlet context listeners - Servlet context attribute listeners - Session attribute listeners" I understnad there's always ONE context object per VM, i.e. in a distributable web app, there can be several context objects, who's state can be differet. Therefore a context init parameters, listeners and attribute listeners can be different too. Sessions are - on the contrary - shared across the the JVM, so that a session attribute listener will always get the SAME events, regardless of which JVM it resides in. This is my understanding, do you agree? /Anders
Hi Anders, There was a fair bit pf explanation given by marcos, wd like to add to it.When a web-application is distributed across multiple JVM's then the Servlet Context is not shared, each JVM/Container has its own instance of the Servlet context, accordingly its own attributes, listeners, attribute listeners.A session can be migrated across and we need to implement the HttpActivation listener to notify the objects whenever the session is abt to move(Passivate) and when it is available(Activate).The attibutes, listeners, and attribute listeners with a session thereby is shared, perhaps it needs to be serialized. Hope this helps..
There’s no place like 127.0.0.1. But I'll always remember this tiny ad: