Web tier: servlets, JSP, Web frameworks: Session migration

  1. Session migration (1 messages)


    Can any one suggest me the ways to migrate the session information from one JVM to another JVM?

    One approach that I know is persisting session information in a database.

    Is there any other way to migrate sessions?

    I am using JBOSS App. Server, and I wanna migrate session from one JVM to another JVM, both JVMs may run in same machine or different machine.

  2. Session migration[ Go to top ]

    Hi Mahesh, I found a similar post on CodeRanch, and someone quotes the From Marcus Green Tutorial to explain this issue very clearly. Here are a few of his main points: * The JSP/Servlet standard requires support for the HttpSessionActivationListener interface, to allow code to be capable of supporting a distributes environment. The HttpSessionActivationListener has two methods: public void sessionDidActivate(HttpSessionEvent se) public void sessionWillPassivate(HttpSessionEvent se) * A container may migrate a session to another JVM for purposes such as load balancing or fail-over. When you say session across different JVM - this means the same session of same web application in different JVM. There is a common misunderstanding on this. For example, an application is deployed in two machines [2 JVMs] Server A and Server B for loadbalancing. If the 1st request for a servlet was fullfilled by ServerA, the next request from the same user can goes to Server B. In this case, the session can persist across the JVMs if the attributes are serialized. * Symmetrical sessions are required with distributed sessions. Otherwise the state will end up spread across the JVMs. This is less efficient than sticky sessions. In symmetrical sessions, when a request is received, the loadbalancer isn't bothered about whether requests have been fullfilled -- it just forwards them to the free Server [A or B]. The JVM and container get the session ID from the cookie, req URL, and gets the data from session, so both JVMs have the session object/attribute. You need to get the session every time as it might have been updated. * Sticky sessions require more intelligence on the load-balancer, but are easier for the JVM. Once a session starts, the load-balancer always sends it to the same JVM. 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 the scenario above, server A is configured to generate a unique session ID eg: 'aaaXXX' and 'baaXXX'. When a request arrived, the load balancer checks the session ID, and if it is empty, it routes the request to any of the servers. (if the request begins with aaa, this means a previous request took place and was fulfilled by ServerA. In this case the load-balancer forwards the request to the same JVM). HTH, Stacey