This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I got problem to understand the numbers of instance when using distributable or not. Can anyone explain this. thanks
Joined: Jan 06, 2001
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
Joined: Oct 17, 2001
Thanks Marcos. Can I test it. It is easier to understand it if I can do some test for it. I also have problem to understand the objective 3.3. Can anyone provide some codes, so I can test it. Thanks.
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..