Friday, 28 October 2011

Glassfish 3.1 cluster: Multiple client thread accessing same session

 I faced a problem while deploying a web application in Glassfish 3.1 cluster. The problem was that HTTPsessions were getting lost haphazardly. I was trying all possible sorts of configurations but the problem was not getting away. While testing the application, I observed that mostly at the time of loading the menu/events of the application the session was getting lost. After giving some load on Google servers, I found the cause of the problem. As per the Glassfish High Availability Administration Guide, if we use Memory Replication in our Web Application and if multiple client threads concurrently access the same session ID, then we may experience session loss without any instance failure. Glassfish 3.1 memory replication framework makes use of session versioning. As our application was using multiple threads concurrently to access the same session ID (mainly at the time of loading menu/events of the page, or on some ajax calls), so the session was getting lost. The solution for this problem was to add <property name="relaxCacheVersionSemantics" value="true"/> in the glassfish-web.xml file.

    <session-manager persistence-type="replicated">
                                <property name="relaxCacheVersionSemantics" value="true"/>
                                <property name="persistenceFrequency" value="web-method"/>

This enables the web container to return for each requesting thread whatever version of the session that is in the active cache regardless of the version number. And voila, I got it right and it worked.