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:
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.
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:
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).
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.
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:
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.
This entry indicates that the server instance running on serverb.activegrid.com at port 8080 is the secondary server for this server.
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.