Session Persistence and Replication

Session Persistence and Replication
This chapter explains how to select a session persistence model, how to change to a different session persistence model, and how to enable session replication. This chapter contains the following sections:
Choosing a Session Persistence Model
When you deploy an ActiveGrid application, you choose how you want to manage session persistence for that application. Whatever session persistence model you use is transparent to the web application itself.
Deployed ActiveGrid applications use one of the following three types of session persistence:
Database: Uses a shared database for session management. Session data is serialized and stored in a database shared by all servers in the cluster. This is a fairly simple way of maintaining sessions. The disadvantage is that, as the number of servers in the cluster increases, the shared database becomes a performance bottleneck. Use for clustered servers only, not single-node servers.
Apache - Single Node: Relies on the underlying file-based session management provided by mod_python or mod_php for maintaining sessions. Use only when deploying to a single node server, or when the load balancer itself supports sticky sessions. This is the default setting for session persistence.
Apache - Distributed Sessions: Uses ActiveGrid’s own distributed session management feature. Allows multiple servers to be configured as a cluster behind a load balancer, while still preserving session state if a request is directed to a new server in the cluster. The session state that was saved on the original server is moved over to the new server. This is the most scalable way of maintaining sessions when cluster sizes start to increase. Use for clustered servers only, not single-node servers.
Changing a Deployed Application’s Session Persistence Setting
To change the session persistence setting for an application after it is deployed, you edit the application's deployment (.dpl) file. To change the session persistence setting, follow these steps:
1.
2.
Within the root element of the .dpl file (ag:deployment) locate the sessionPersistence attribute. The value of the sessionPersistence attribute specifies the session persistence setting for the application. If no sessionPersistence attribute attribute is specified in the ag:deployment element, then the application is deployed with the default session persistence model (Apache - Single Node).
3.
Delete the existing value of the sessionPersistence attribute and type in the value corresponding to the type of session persistence you want:
The setting for Apache -Single Node session persistence.
The setting for Database session persistence. If you use this setting, you also need to set the sessionDataSource attribute to reference the data source that stores the session information. The data source that you reference in the sessionDataSource attribute must be described in a ag:datasource element in the deployment file (“The DataSource Element” on page 41).
The setting for Apache - Distributed session persistence.
If no value exists, the server uses the default value, which is EXTERNAL.
Note: You need to set the sessionDataSource attribute only when using the DATABASE setting.
Configuring Session Replication
By default, ActiveGrid Servers use dynamic session replication. With dynamic session replication, sessions are automatically replicated on some number of servers in the cluster. The number of servers on which the session is replicated is specified by the sessionRedundancy attribute on the ag:deployment element in the deployment file (“The Deployment Element” on page 36).
In the deployment file, set the sessionRedundancy element to any integer greater than or equal to zero. A value of zero (the default) means the session is not replicated. A value of one means that the session is replicated on one other server in the cluster. A value of two means that the session is replicated on two other servers, and so on.
Configuring Static Session Replication
If you prefer, you can use “static” session replication, rather than dynamic session replication. The static session replication configuration allows a session to be replicated on two servers in the cluster. Each server is able to provide up-to-date session state if required. This enables the cluster to be more resistant to losing session information if a single server in the cluster goes down.
Each server in the cluster can have up to one other server designated as its secondary server. This means that a copy of all sessions stored on the primary server also exists on the secondary server. The secondary server, in-turn, can be a primary server in its own primary-secondary relationship. For example, a typical cluster setup might look like the following:
server A primary -> server B secondary
server B primary -> server C secondary
server C primary -> server A secondary
This allows each server in the cluster to have one additional backup, so that there is no single point of failure.
This feature is not automatically enabled. To enable this feature, edit the INSTALL_DIR/local/conf/activegrid.conf file on each primary server. To each file, add a single configuration entry that specifies the secondary server. After you edit the activegrid.conf file, restart the server for the change to take effect.
Here is a configuration entry example:
ActiveGridSecondarySessionServer http://serverb.activegrid.com:8080/ag_sess_api
This entry indicates that the server instance running on serverb.activegrid.com at port 8080 is the secondary server for this server.
Using ActiveGrid’s Session Management Functions
The mod_activegrid module is the Apache 2.x.x module that provides ActiveGrid Server's grid computing and adaptive transaction management capabilities. Currently, mod_activegrid provides the basic functionality necessary for the distributed session management support in the server.
Once loaded, mod_activegrid allows other Apache modules such as mod_python, mod_php, mod_perl, or other user developed web application modules, to invoke mod_activegrid's session management functions. These modules use HTTP POST requests to access session management functions at request processing runtime.

ActiveGrid
Installation and Deployment Guide
Version 2.0