Stateful Session Clustering: Have Your Availability and Scale It Too : Page 2
Stateful application design is just what Java developers need for clustering HTTP sessions. It is easier to code to, more scalable, and more cost effective, and by combining it with network-attached memory, developers can avoid Java serialization while storing state in a central place.
by Ari Zilka
Oct 2, 2006
Page 2 of 4
The Two Tenets of Session Clustering
At the core of all the session clustering challenges are two key competing needs:
An infrastructure service that provides a physical location where all sessions are stored. Like a database, or a SAN, a central repository would eliminate the complexities of load balancing. This is the fundamental premise behind stateless Web application design. The concepts of session primary/secondary and sticky session need no longer apply.
Avoiding any marshaling/un-marshaling to move data between the application server and the session repository, or onto other application servers. If the session is serialized, too much data moves between cluster members and you immediately lose the ability to cluster certain open source frameworks and libraries. This is the fundamental premise behind stateful Web application design.
Essentially, the need is for parts of stateless and parts of stateful application architectures. Going one step further, these needs can be translated into two tenets of session clustering:
Tenet 1: Store session in a central location so that application servers can behave in a hybrid stateful/stateless manner, choosing unilaterally to drop certain sessions from heap as load increases.
Tenet 2: Never use Java serialization to get the session data from app server heap into the central session store. Furthermore, don't use any object-graph snapshot techniques. You instead need a fine-grained way to keep track of objects, cluster-wide, and then push only deltas to the cluster members that need those object deltas. Otherwise, your clustering technology will not scale and it will push the scaling burden onto the application developer.
These two tenets work together to define the previously discussed notion of network-attached memory (see Sidebar 1. Honoring the Tenets with Network-Attached Memory). Tenet 1 states that NAM is a physical server, separate from your application servers. Tenet 2 states that its interface must be the JVM's heap so that you can avoid serialization both in concept and in fact.