HTTP Session Management

The GigaSpaces-Jetty integration comes with a support for storing the javax.servlet.http.HttpSession in the Space Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model. allowing supporting session replication and failover between different web application instances deployed into GigaSpaces containers.

The GigaSpaces HTTP Session Management provides the following:

• Avoid using database as the persistent storage media - Better performance and simplify the deployment

• Allow management and control of full lifecycle of web application - From the load-balancer to the data

• Dynamic scalability - Allows the web application to scale up or down based on SLA

• Continuous High-Availability - Allows the application to survive any system failures

• Non intrusive session management or explicit Data Grid API access for fine grain control - Allows multiple web servers to share the same session in transparent manner

How to enable HTTP Session Management

There are several ways to configure Space session based support, depending on the definition of which Space and how the Space was started.

Using the Deploy Property

Here is how you can deploy an existing WAR file without changing it (or use Spring) to use GigaSpaces HTTP Session Management:

gs deploy -properties embed://jetty.sessions.spaceUrl=jini://*/*/sessionSpace?useLocalCache myWar.war

curl -X POST --header 'Content-Type: application/json' --header 'Accept: text/plain' -d '{ 
   "name": "myWar", 
   "resource": "myWar.war" 
 }, 
   "contextProperties": {embed://jetty.sessions.spaceUrl=jini://*/*/sessionSpace?useLocalCache} 
 }' 'http://localhost:8090/v1/deployments'

Using Spring

When deploying, include within the META-INF/spring/pu This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity..properties file the jetty.sessions.spaceUrl property value. This should be set with the space url defining where the sessions will be stored.

For example, if the session will be stored on a remote clustered Space with local cache, the URL can be: jini://*/*/sessionSpace?useLocalCache (assuming the name of the Space is sessionSpace). If the session should be stored on a Space that should be started within the web application (in a collocated manner) in a sync_replicated cluster schema (for example), then the url can be /./sessionSpace?cluster_schema=sync_replicated (note, cluster ids will be automatically set based on the number of web applications deployed).

In case there is already a Space configured within the web application. For example, defined within META-INF/spring/pu.xml, it can be used as the Space where sessions will be stored as well. In this case, the jetty.sessions.spaceUrl can use the special prefix bean. For example, if the Space was defined as a bean with id of sessionSpace, the jetty.sessions.spaceUrl can be set to bean://sessionSpace.

Options

Controlling the session Management done via the following properties:

Deployment Topologies

The HTTP Session support several Deployment Topologies:

Embedded Replicated

Supports only a limited amount of sessions.

Partitioned+Replicated

• Session Data is partitioned across multiple machines.

• Allows unlimited amount of data to be stored in memory.

  

Partitioned+Replicated with Local-Cache

• Support for read mostly scenario via local cache running within the application server memory address. Avoid remote calls when there are repeated read calls for Session data that are stored in memory across multiple machines.

• Provide total linear scalability.