Session State Caching Powered by GemFire enables you to manage the session state for your applications independently of your application servers. This enables you to remove or reconfigure application servers as needed without affecting the session lifetime. It also enables clients to load balance between application servers without concern for the location of a particular session state.

Session State Caching Powered by GemFire is optimized for Java buildpack applications that are deployed in Tomcat. These applications require no additional configuration to utilize the service. The service’s credentials are automatically discovered when you bind a java buildpack app to the service. In turn, Pivotal Cloud Foundry® (PCF) application developers can rapidly connect a running Session State Caching service to their Elastic Runtime-hosted applications.

As with other Pivotal Cloud Foundry® data services, Pivotal Cloud Foundry® administrators can now import, configure and define a Session State Caching service plan that uses GemFire for their Pivotal Cloud Foundry® Elastic Runtime environments. Pivotal also provides the Pulse Web application to help you monitor the service instances that you deploy.

GemFire Cache Configuration

Session State Caching Powered by GemFire is implemented as a pre-configured GemFire cluster running on Pivotal Cloud Foundry®. A single region named sessions is configured to store the session state data. This region has the following characteristics:

  • The sessions region is partitioned across all available cache servers in the cluster. Redundant copies of the data are maintained to prevent service interruption or data loss in the case of a single cache server failure.
  • The region is configured for persistence, so you can reconfigure and restart the GemFire cluster without losing the available session state data.
  • Overflow is configured to write data to disk when JVM heap usage reaches 70%, to help protect from memory pressure.

Note: Although the service enables GemFire HA features such as redundancy and persistence, the service is limited to a single Cloud Foundry availability zone. See the Release Notes for more information.

How Does the Service Work?

The following diagrams depict the high-level workflow for deploying the Session State Caching service.

Figure 1. Installing and Configuring the Service

GemFire on CF Deployment

  1. Pivotal Cloud Foundry® Administrator imports the Session State Caching product file into Pivotal Cloud Foundry® Operations Manager.

  2. When a Pivotal Cloud Foundry® Administrator configures the Session State Caching service for the first time, they define the number of discrete Session State Caching service instances, each composed of five virtual machines, that they wish to make available to Pivotal Cloud Foundry® developers. Two VMs each run the SSC GemFire Locator process, and three VMs each run the SSC GemFire Server process.

  3. After making their configuration choices, the Pivotal Cloud Foundry® Administrator deploys the service, causing Pivotal Cloud Foundry® Ops Manager to create and setup the appropriate set of virtual machines.

  4. Operations Manager deploys a virtual machine to run a software component known as the SSC GemFire Service Broker, which is responsible for allocating Session State Caching service instances to Pivotal Cloud Foundry® users and passing relevant information into the applications that are bound to each service instance.

  5. Operations Manager also deploys the specified number of GemFire cluster instances as configured by the administrator. Lastly, there are a few temporary VMs used for install and uninstall errands.

After the service has been deployed in Operations Manager, it is ready for use by application developers in the Elastic Runtime environment. The following diagram depicts the high-level workflow that an application developer would use to consume the service.

Figure 2. Using the Service

Data Service Work Flow

  1. Pivotal Cloud Foundry® Developer uses the CLI or Developer Console to create a Session State Caching service instance in the Elastic Runtime space where they are pushing the relevant applications.

  2. Creating a service instance causes Elastic Runtime to contact the SSC GemFire Service Broker, which allocates one un-allocated GemFire cluster of virtual machines to the Session State Caching service instance. In the response to Elastic Runtime, the Service Broker includes the URL to reach the GemFire Pulse monitoring tool for the service instance. The Elastic Runtime exposes this URL in the Developer Console’s metadata for the service instance.

  3. Pivotal Cloud Foundry® Developer pushes their application to Elastic Runtime.

  4. Pivotal Cloud Foundry® Developer binds their application to the Session State Caching service instance. The SSC GemFire Service Broker populates the application’s VCAP_SERVICES environment variable with the metadata required to access the Session State Caching service instance’s locators and cache servers.


This document describes Session State Caching Powered by GemFire, version The Session State Caching Powered by GemFire service is running Pivotal GemFire 8.0.

Additional Resources

Create a pull request or raise an issue on the source for this page in GitHub