• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Servlet Context in Clustered Environment

 
Vaibhav G Garg
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1376
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1376
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic