From Marcus Green Tutorial :- The JSP/Servlet standard does not require that a web container supports distributed applications, but it must support the HttpSessionActivationListener interface, to allow code to be capable of supporting such an environment. The HttpSessionActivationListener has two methods.
public void sessionDidActivate(HttpSessionEvent se)
public void sessionWillPassivate(HttpSessionEvent se)
The specification mandates that a container may migrate a session to another JVM for purposes such as load balancing or fail-over. This type of capability is considered vital for the deployment of large scale web application
Session passivation is where inactive sessions are written to a persistent store. Session activation is the ability to a previously passivated session into memory from the persistent store. For an attributes to be migrated between distributed JVM's any attributes must implement the java.io.Serializable interface. This is not a very taxing programming task as Serializable is a marker interface i.e. it has no methods. .
With the exam perspective , the above things are enough to know.
If you hav the ask Q to implement then you shd knw few more things.
Load balancing with multiple machines either uses sticky sessions or symmetrical sessions.Sticky sessions put more intelligence on the load balancer, and symmetrical sessions puts more intelligence on the JVMs. The choice of which to use depends on what kind of hardware you have, how many machines you're using and how you use sessions.
Symmetrical Sessions
Symmetrical sessions happen with dumb load balancers like DNS round-robin. A single session may bounce from machine A to machine B and back to machine B. For
JDBC sessions, the symmetrical session case needs the always-load-session attribute described below. Each request must load the most up-to-date version of the session.
Distributed sessions in a symmetrical environment are required to make sessions work at all. Otherwise the state will end up spread across the JVMs. However, because each request must update its session information, it is less efficient than sticky sessions.
Sticky Sessions
Sticky sessions require
more intelligence on the load-balancer, but are easier for the JVM. Once a session starts, the load-balancer will always send it to the same JVM. Resin's load balancing, for example, encodes the session id as 'aaaXXX' and 'baaXXX'. The 'aaa' session will always go to JVM-a and 'baa' will always go to JVM-b.
Distributed sessions with a sticky session environment add reliability. If JVM-a goes down, JVM-b can pick up the session without the user noticing any change. In addition, distributed sticky sessions are more efficient. The distributor only needs to update sessions when they change. So if you update the session once when the user logs in, the distributed sessions can be very efficient.
In Simple words : -
1) When you say session across different JVM - It means same session
of same web application in different JVM. There is a common misunderstanding on this.
Mean suppose I have an application like javaranch which is deployed in two machines[2 JVM]Server A and Server B for loadbalancing.Then if suppose 1st request for a
servlet was fullfilled by ServerA , the next request frm same user can go to Server B .In this case session can persist across the JVM's if attributes are serialized.
2)In Symmetrical Sessions, When a request come,the loadbalancer is never bothered abt whether where any req has been fullfilled by this user,it just fwd he req to free Server [A or B]. The JVM and container will get the sessionid from cookie ,req url and will get the data from session.both JVM's nw have the session object/attribute .In Symmetrical Sessions, we need to get the session everytime as it may have got updated .
3)In Sticky sessions, logic is in loadbalacer. In the scen, Server A will be confg to generate sessionid strtg with som unique se eg:'aaaXXX' and 'baaXXX'. So when a req come loadbalancer will check the sessionid ,if it is empty it will route the req to any of the server.
if it strts with aaa, then that means a prev req has com and was fulfilled y ServerA, so loadbalancer will forward the req to same JVM.
Some chnage in DD is also reqd.I am not sure on that.
Sorry for the big reply.
Thanks,
Chithra Salam.
SCJP-85%,SCWCD-in Progress.
