hey, can somebody help me understand this. I remember reading it sometime back(or maynot!!) Can we have a web container running on multiple JVMs. If so what would be the rules that the container has to follow for maintaining sessions i mean are they the same as for a single JVM? thanks, P C L
"p c l" your name doesn't agree with the javaranch guidelines. please take a moment and re-register after reviewing the guidelines at http:www/javaranch.com/name.jsp thanks for your cooperation - satya
Support for applications distributed across multiple JVMs is a fundamental part of J2EE. This allows scaling up and better sail-safe operation because you can cluster servers etc. A JSP/Servlet session is tied to the URL name (not the URI, just the URL). It's up to the server to work out how that session object gets from one JVM to another (if the server supports such operation).
An IDE is no substitute for an Intelligent Developer.
Joined: Aug 28, 2001
Tim, here is where i read about distributed applications but can u explain me what "more than one Java VM " means "Developers writing distribtued applications shoule be aware that since the container may run in more than one Java VM,..." Container meaning i suppose it is the web container. I was confused by the line which said it can run on mulitple JVMs. BTW i got this info from the Java servlet specification (2.3) section 7.7.2 (distributed environments) last paragraph.
Maybe this will help :- here's a description of how I run one of my machines: A single machine runs Linux and listens to several IP addresses. Two of those addresses are used for a DNS server, so the rest of the internet can ask for the IP address of any of the domains hosted on this one machine. Another one of the IP addresses has an Apache web server listening to it which serves web pages, servlets and JSPs etc. to anyone who asks. Now, the same machine is "pretending" to be more than one named machine (in this case, say, www.servletshop.net, test.servletshop.net, www.hrcc.org.uk and www.opengateplaygroup.org) and we don't want anyone coming to one of these sites getting content from one of the others. So we use "virtual hosting". Apache is told about all the domains in its config file, and they each are served from a separate place on the hard disc. But now we get to the Java side of things. There are several ways we can support servlets, JSP etc. in a setup like this. The first, and probably the most common is to run a single JVM running a single instance of a Servlet/JSP container (Tomcat, Resin, JRun etc.) Modern Servlet Containers understand the idea of "web applications" and "virtual hosts" which have their own classloaders, sessions and so on and keeps a most things separate. But there is a problem. A deliberate or accidental mistake (like badly-configured security properties and an inadvertent call to "System.exit()" can cause the JVM to terminate, killing everything in all the hosts and web applications and potentially losing all their session and application data too. If this might be a problem (for example where different people have deploy-level access to web-applications on different virtual hosts) then a more robust way is to have each user's web applications in their own instance of the Servlet Container. For example, the system described (with the four machine names) might be running one Apache process and four Tomcat or Resin processes, with Apache passing calls to whichever one is specified in the URL. This way, a call to System.exit() can only break at most one of the sites, leaving all the others running with no problems. To run these four Servlet Containers, we need to use a separate "java" command for each, something like:
Now, each Servlet Container is running in its own Java Virtual Machine. It's unususl in this sort of setup to want to share sessions, but if you do, some Servlet Containers allow you to specify that session data be persisted to a file store or database, and can thus be read by any of the JVMs. Another case where you might want to run more than one Servlet Container at once is for backup purposes. In this case you would start them with the same configuration, but different ids, and tell the hosting web server (eg. Apache) to fallback to number 2 if number 1 fails, or to alternate between them. In this case you will want to share session data, so persistent sessions in a file system or database is a must. The final case is where one machine is not powerful enough to serve all your servlet or JSP requests. In this case you would use a setup much like the previous one, load-balancing between various JVMs running on different physical machines. In this case it's unlikely that persisting sessions to a file system would be much use, so it's most popular to share them via a database or even by multicasting the data between the cluster of machines when anything changes. Has this helped? [This message has been edited by Frank Carver (edited August 29, 2001).]