wood burning stoves 2.0*
The moose likes Servlets and the fly likes Servlet Context in Clustered Environment Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Servlet Context in Clustered Environment" Watch "Servlet Context in Clustered Environment" New topic
Author

Servlet Context in Clustered Environment

Vaibhav G Garg
Ranch Hand

Joined: Sep 23, 2011
Posts: 140
We have added some of the attributes in the HTTPSession object and also in servletcontext attributes as well.

I would like to know if these will work correctly in clustered environment since the application will be deployed in different servers so can the attributes added in context will work correctly over there?

If not, then what is the possible solution for this.
Abhay Agarwal
Ranch Hand

Joined: Feb 29, 2008
Posts: 1075
    
    1

In cases where the container is distributed over many virtual machines, a Web application will have an instance of the ServletContext for each JVM.

Context attributes are local to the JVM in which they were created. This prevents ServletContext attributes from being a shared memory store in a distributed container. When information needs to be shared between servlets running in a distributed environment, the information should be placed into a session , stored in a database, or set in an Enterprise JavaBeans component. Session attributes must be serializable if they are to be processed across multiple JVMs, which is a requirement for clustering. It is possible to make some fields of a session attribute non-clustered by declaring those fields as transient.


Abhay Agarwal
Ranch Hand

Joined: Feb 29, 2008
Posts: 1075
    
    1

Just to add on, The following are our own rules of thumb for writing servlets to be deployed in a distributed environment:
• Consider that different instances of the servlet may exist on each different JVM and/or machine. Therefore, instance variables and static variables should not be used to store state. Any state should be held in an external resource such as a database or EJB (the servlet's name can be used in the lookup).
• Consider that a different instances of the ServletContext may exist on each different JVM and/or machine. Therefore, the context should not be used to store application state. Any state should be held in an external resource such as a database or EJB (the context's path can be used in the lookup).
• Consider that any object placed into an HttpSession should be capable of being moved to (or accessed from) a different machine. For example, the object can implement java.io.Serializable. Be aware that because sessions may migrate, the session unbind event may occur on a different machine than the session bind event!
• Consider that files may not exist on all backend machines. Therefore, you should avoid using the java.io package for file access and use the getServletContext().getResource( ) mechanism instead--or make sure all accessed files are replicated across all backend machines.
• Consider that synchronization is not global and works only for the local JVM.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Servlet Context in Clustered Environment
 
Similar Threads
Terminate others session by session id
Get session object from session ID
How to run code on server startup?
JBoss 5.1.1 Cluster Restart
static variables in EJB bean