sessions-state.pdf

7/30/2019 Sessions-state.pdf

1/5

1.

2.3.

Infrastructure for Stateful Web Applications

1 Introduction2 Horizontal Scaling3 Stateless Applications

4 Stateful Applications4.1 Sessions

4.1.1 Stickies4.1.2 Session Sharing and Replication4.1.3 Client Side State

5 Recommendation

Introduction

This describes the different web infrastructure that could be used to support stateful web applications and the implementation strategy that isrecommended by the Web Support team.

A stateful web application maintains states between pages over a period of time. These applications typically have logins and/or are requiredto keep track of the state the web session. Examples are applications that does flight booking, muliple page flight searches, multiple pagefinance computations and shopping carts. Stateless applications are generally less complex and easier to implement. They also tend to beeasiser to scale horizontally. While it is desirable to have less complexity associated with an application, business requirements will ultimatelydictate the need to have stateful applications.

The objectives of this paper are

Informational - to enable better design decisions in development, to help management make resource decisions and businessimpacts.Provides a guide for implementation - helps the implementers to understand the underlying design conceptsSupport - enables better support decisions that will help evaluate impact of restarting of multi-noded statless web applications.

Horizontal Scaling

Scaling a web application refers to the ability to add resources to enable the application to meet its performance requirements. When anapplication is deployed there are 2 ways to meet its initial resource requirements. One way is to provide sufficient resources locally to thedeployed node. Example of which are added more memory or CPU. This method is also commonly call vertical scaling. The other way is tohave it scale horizontally by having more servers for the application. This requires that the service be distributed across multiple machines.

Horizontal scaling could easily be achieved if the application is stateless. It can be done by simply having a load balancer in front todistribute requests to the service across the configured servers. In theory horizontal scaling is only limited by how many machines you haveavailable for the application. It is is massively scalable, quick to add or reduce the system capacity with minimum or no impact to businesscontinuity. It is also robust because it provides multiple points of failures. For these reasons horizontal scaling is the preferred way oververtical scaling.

Stateless Applications

If at all possible an application should be stateless as it will be simply deployments and configurations. but maily it works really well withhorizontal scaling. A stateful application can usually be made to behave like a stateless application. This can be done by example by keepingthe states on the client (browser) of the web application by using application cookies. Encryption could be used to make it more secure. Thisis the client side state describe below. Basicaly state is kept in some sort of user cookies on the client (see diagram).

.

Stateful Applications

Sessions

Application states are usually kept in session objects provided by the application container. E.g Jave provides sessions objects which

provides the abstraction into the container session objects that Tomcat, Weblogic, Jboss or WebSphere provides. There are basically 2 waysto implement a multi-node stateful application. One way is session sharing the other is to use sticky sessions.


2/5


3/5

Stickies

Sticky sessions is the simplest way to implement a stateful application. Normally the load balancer in front of the application node will eitherselect the node to send the request to based on whatever algorithm that is configured for it. Since there is no garantee that the same nodewill be used each time a new request is made, any context or state that is kept on the node could potentially be lost. Using sticky sessions(implemented by cookies), the same end node or any intermedia nodes will be used each time a request is made. This enables state to bekept in the nodes between muliple requests.

The down side to sticky sessions is that when a node goes down, the user will loose states stored in the node sessions. E.g. A User hat torelogin when a node is restarted.

Session Sharing and Replication

Session sharing is another way to support stateful applications. Session sharing can be achieved by application server level clustering orhaving persistent data store for the sessions. Sessions are replicated across the clustered nodes to provide a single application view of thesession. Session replication is inherently plagued with complexities (square) and susceptble to underlying instabilities. It should be avoidedwhenever possible.

Persistent sessions/states basically means a copy of the "session/state" is stored in either a shared file system or database and will beaccessed by all the application nodes. It can either be implemented in the application or by the application container. In general it would bebetter to use the persistent service provided by the application container. Unfortuately the current implemenation of session persistance bytomcat/(and likely Jboss) is inadequate. There are issues related to stale session state accross nodes.

Client Side StateAlternatively, the state of an application can kept on the client side by storing data in user cookies. This can be made more secure byencyption.


4/5

RecommendationNone of the implementation strategy by themselves are adequate to support seamless stateful application. The recommened approach is touse a combination of sticky sessions and persistent sessions for 1) application that requires totally seamless stateful nodes. 2) sticky sessionfor stateful nodes that could tolerate short temporary loss of service.


5/5

sessions-state.pdf

Documents