question on servlet contexts

[Rajani Gummadi]

Hi,

I was reading through the api for "ServletContext" at http://download.oracle.com/javaee/1.4/api/javax/servlet/ServletContext.html and it says

"There is one context per "web application" per Java Virtual Machine. (A "web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file.)

In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine. In this situation, the context cannot be used as a location to share global information (because the information won't be truly global). Use an external resource like a database instead. "

In both the cases, distributed and non-distributed, it seems there is only one context per virtual machine. So how are these two things different.

Does the distributed web app, having several instances running on different nodes, share the same virtual machine.

[T. Huy Nguyen]

Rajani Gummadi wrote:Hi,

In both the cases, distributed and non-distributed, it seems there is only one context per virtual machine. So how are these two things different.

Does the distributed web app, having several instances running on different nodes, share the same virtual machine.

If instances of a same distributed webapp runs on different nodes, they must have their own VMs. They must have had some form of communication to make them "distributed", but they dont share a VM.

[Gaurav Sagar]

Rajani Gummadi wrote:Hi,
I was reading through the api for "ServletContext" at ...... running on different nodes, share the same virtual machine.

There is only one JVM per node, so definitely its not shared by different nodes, rather each have its own JVM. While every part of the web-application is replicated on each node, such as servlets, JSP, servlet-context, etc. Its only the HttpSession objects that are migrated/moved between the nodes. Lets say that a request comes from a client to the web-app, the load-balancer server delegates the request to node 1, there the session object is created and the response is sent back to client along with session cookie.

Now, the client again makes a request sending in the session-id, now the load-balancer server delegates the request to node 2, which doesn't have that session object, which is realized by the container at node 2. Now the question arises how to process the request. Hence, there is now session migration i.e. the specific session (found by its session id)is passivated on JVM at node 1, and activated on JVM at node 2.

Having the session, since as told before every thing is replicated. The container creates a new thread of servlet A(assuming the request was bound to it) and processed response is sent back to the client. This is a general view of how distributed applications work.

Regards,
Gaurav

[Rajani Gummadi]

Thank for the explanation.

Now as mentioned, entire web app is replicated in every node in the distributed environment. That means I assume that same .war file is deployed individually in each node , in individual containers. Now as you mentioned, when the subsequent request comes and load balancer delegates the request to say node 2, which does not have the associated session in its jvm, how does the container at node 2 knows, that a session was actually passivated at node 1 and how would it make that session activated at node 2. How does this communication takes place?

Also, what if different containers (I mean weblogic, websphere etc) are used for each of these nodes) and how does the session activation/passivation takes place.

[T. Huy Nguyen]

Session-replication is a container-specific service. Different container (Weblogic, Websphere) may have different implementation, and thus exhibit different behavior. You'd better consult the documentation of each container to find out how their session-replication work.

And because session-replication is container-specific, I seriously doubt if it still works when different container (WLS, Websphere) are used for each nodes.

I also don't remember "session passivation/activation" mentioned in Weblogic documentation before.

[Abimaran Kugathasan]

Rajani Gummadi wrote:Hi,

I was reading through the api for "ServletContext" at http://download.oracle.com/javaee/1.4/api/javax/servlet/ServletContext.html and it says

"There is one context per "web application" per Java Virtual Machine. (A "web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file.)

In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine. In this situation, the context cannot be used as a location to share global information (because the information won't be truly global). Use an external resource like a database instead. "

In both the cases, distributed and non-distributed, it seems there is only one context per virtual machine. So how are these two things different.

Does the distributed web app, having several instances running on different nodes, share the same virtual machine.

How do think, that a JVM can be shared within multiple nodes? We can't. There are some restriction on the web application, if you make it as distributed,

Don't use context attributes to share state between servlets--Context attributes are stored in ServletContext and are shared by all servlets in a Web application. But context attributes are specific to the JVM instance in which they were created. Servlets that communicate by sharing context attributes may not operate properly if distributed, because context attributes do not replicate between Web containers in different JVM instances. To share data between distributed servlets, place the data in a session object, store it in the EIS tier in a database or distributed cache, or use an enterprise bean.

One exception to this guideline is to use context attributes as a shared data cache between the servlets in each Web container. Cache hits and misses affect only an application's performance, not its behavior.

Have a look on this