Web-layer state replication for Java EE applications

Most WEB applications of some importance require maintenance of a session state, such as the contents of a user's shopping cart. How you manage and replicate state in a clustered server application has a significant impact on the scalability of your application. Many J2SE and Java EE Applications store state in the HttpSession provided by the Servlet API. The author of this article analyzes some of the options for State replication and how to use HttpSession most effectively to provide good scalability and performance.

Whether you are building a Java EE or a J2SE server application, it is possible to use the servlet--in some way, either directly through a presentation layer such as JSP technology, Velocity, or Webmacro, or through a Servlet based Web service implementations, such as Axis or Glue. One of the most important functions provided by the Servlet API is session management-authentication, expiration, and maintenance of user status through the HttpSession interface.

Session state

Almost every WEB application has a session state that can be as simple as remembering whether you are logged on or a more detailed history of your session, such as the contents of a shopping cart, a cache of previous query results, or a complete response history of a 20-page dynamic questionnaire. Because the HTTP protocol itself is stateless, the session state needs to be stored somewhere and associated with the browsing session in a way that makes it easy to retrieve the next time a page of the same WEB application is requested. Fortunately, Java EE offers several ways to manage session state-the state can be stored in the data tier, stored in the WEB layer with the Servlet API's HttpSession interface, and stored in a stateful session bean at the Enterprise JavaBeans (EJB) layer. Even use cookies or hide form fields to store the state at the customer level. Unfortunately, improper session state management can cause serious performance problems.

This method is usually better than other methods if the application can store user state in HttpSession. Storing session state with HTTP cookies or hidden form fields on the client is a significant security risk-it exposes part of the application's internal content to the untrusted customer layer. (An early E-commerce Web site stores shopping cart content (including prices) in hidden form fields, which can be easily exploited so that anyone who understands HTML and HTTP can buy any item for 0.01 dollars.) Oh. In addition, using cookies or hiding form fields is confusing, error-prone, and fragile (if the user forbids cookies in the browser, the cookie-based approach is completely out of the way).

Other ways to store server-side state in a Java EE application are to use stateful session beans or to store session state in a database. Although stateful session beans have greater flexibility in session state management, it is still beneficial to store session state in the Web tier where possible. If the business object is stateless, it is generally possible to simply add more Web servers to extend the application without adding more Web servers and more EJB containers, which is generally less expensive and easier to complete. Another benefit of using HttpSession to store session state is that the Servlet API provides an easy way to notify when a session fails. The cost of storing session state in the database may be unbearable.

The servlet specification does not require a servlet container to perform some type of session replication or persistence, but it recommends that State replication be an important part of the servlet's primary raison d ' etre, and that it raison a number of requirements as a container for session replication. Session replication can provide a number of benefits-load balancing, scalability, fault tolerance, and high availability. Accordingly, most servlet containers support some form of HttpSession replication, but the mechanism, configuration, and timing of replication are determined by implementation.

HttpSession API

Simply put, the HttpSession interface supports several methods that servlet, JSP pages, or other presentation layer components can use to maintain session information across multiple HTTP requests. The session is bound to a specific user, but is shared in all the servlet of the WEB application--not specific to a servlet. A useful way of thinking about sessions is that a session is like a map--that stores objects during a session and can use SetAttribute to store session properties by name and extract them with getattribute. The HttpSession interface also contains the session lifetime method, such as Invalidate (), which notifies the container that the session should be discarded. Listing 1 shows the most commonly used elements of the HttpSession interface:

Listing 1. HttpSession API

public interface HttpSession {
　Object getAttribute(String s);
　Enumeration getAttributeNames();
　void setAttribute(String s, Object o);
　void removeAttribute(String s);
　boolean isNew();
　void invalidate();
　void setMaxInactiveInterval(int i);
　int getMaxInactiveInterval();
　...
}

Theoretically, the session state can be completely replicated across the cluster, so that all nodes in the cluster can serve any request, and a simple load balancer can send requests in polling mode to avoid the failed host. However, this compact replication has high performance costs and is difficult to implement, and there are scalability issues when the cluster approaches a certain size.

A more common approach is to combine load-balancing session similarity (affinity)-a load balancer can associate sessions with connections and send future requests from a session to the same server. There are many hardware and software load balancers that support this feature, and this means that only primary connection hosts and sessions need to fail over to another server to access replicated session information.