Stateful Session Clustering: Have Your Availability and Scale It Too
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
October 2, 2006
ll conversational Web applications are stateful, but the question is where to keep the state. For HTTP session clustering, the answer is keeping session in memory, closer to the processing context where it is needed. This is because data stored in session has no business value; session is just a temporary place to keep state while an application converses with a browser. The conversation occurs over the course of several network calls that take a significant amount of time (seconds, minutes, or hours).
Still, popular opinion regarding which application design is right for clustering HTTP sessions has swung back and forth between stateful and stateless. Today, the pendulum hovers squarely over stateless application design, but the Java community needs stateful application design. Many critical frameworks that Java developers use to build Web applications rely on session to be durable across requests—in other words, stateful. Struts, Spring Web Flow, RIFE, AJAX, and others keep track of per-user information that needs to remain in memory. Otherwise, the application can survive logically, but the end-user experience is not ideal. Shopping carts get lost; checkout starts again; log-ins are dropped and users have to re-enter passwords; complicated multi-stage Web forms have to be filled in from scratch, and so on.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
ll conversational Web applications are stateful, but the question is where to keep the state. For HTTP session clustering, the answer is keeping session in memory, closer to the processing context where it is needed. This is because data stored in session has no business value; session is just a temporary place to keep state while an application converses with a browser. The conversation occurs over the course of several network calls that take a significant amount of time (seconds, minutes, or hours).
