Browse Prior Art Database

Session sharing in a cluster of Java Servers Disclosure Number: IPCOM000014257D
Original Publication Date: 2000-Feb-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 3 page(s) / 44K

Publishing Venue



Session sharing in a cluster of java servers

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Session sharing in a cluster of Java Servers

Session sharing in a cluster of java servers

Implementations of Java Web Servers such as IBM's WebSphere Application Server have rapidly gained in popularity due to the ease of implementation and testing of Web applications, using servlets and JavaServer Pages (JSP) provided by these servers. Customers conceive, build and deploy servlets without necessarily considering that their applications may be more successful than they thought and may require distribution over a cluster of servers in order to scale. A problem arises when sessions involving separate requests are distributed over a cluster of servers and the session data is only present on one server, so that only that server can actually take the subsequent requests.

When the application design considers distribution, this is often performed at the application level using a back-end data system, increasing the development cost, and forcing the designer to write some amount of session management support. This is opposite to the servlet philosophy. In fact, the Servlet API, since JSDK 2.0, provides a powerful Session Tracking API. Every user of a site is associated with a javax.servlet.http.HttpSession object. Servlets can use this session object to store or retrieve information about the session of each user. Any set of arbitrary Java objects, such as a database connection or a shopping cart, can be saved in a session object. But the session tracking scope is limited to a single physical Application Server and does not distribute.

When the application design does not consider distribution, it can use the Servlet API to manage sessions, but this will not scale to a cluster of servers.

IBM's Network Dispatcher proposes a source IP affinity as a bypass, but this solution has disadvantages: * limits the load balancing to session-level granularity so that if a server is put offline, the whole session is lost * is defeated by clusters of socks servers that present different IP addresses for the same client * is mislead by intermediate proxies that group many clients under a same IP address
* has limited consistency over time

IBM's content based router proposes a cookie affinity as an improvement to client IP address affinity, but this has disadvantages also:
* it runs on top of a proxy so it limits the capacity of the cluster by rapidly becoming the bottleneck * session IDs may be carried though URLs and parameters as well as cookies. But not all clients will accept cookies anyway, and the Java WebServer has the ability to revert to using URL rewriting when cookies fail * this still limits the load balancing to session-level granularity


Page 2 of 3

The proposed solution distributes the Application Server session objects using an object broker such as Java's Remote Method Invocation (RMI). Basically it improves the current implementat...