17. Spring Session

There is nothing special that you need to do in order to use either Apache Geode or Pivotal GemFire as a Spring Session provider, managing the (HTTP) Session state of your Spring Boot application.

Simply include the appropriate Spring Session dependency on your Spring Boot application’s classpath, for example:

Maven dependency declaration. 

  <dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-geode</artifactId>
    <version>2.3.0.M2</version>
  </dependency>

Alternatively, you may declare the provided spring-geode-starter-session dependency in your Spring Boot application Maven POM or Gradle build file:

Maven dependency declaration. 

  <dependency>
    <groupId>org.springframework.geode</groupId>
    <artifactId>spring-geode-starter-session</artifactId>
    <version>1.3.0.M2</version>
  </dependency>

After declaring the required Spring Session dependency, then begin your Spring Boot application as you normally would:

Spring Boot Application. 

@SpringBootApplication
public class MySpringBootApplication {

  public static void main(String[] args) {
    SpringApplication.run(MySpringBootApplication.class, args);
  }

  ...
}

That is it!

Of course, you are free to create application-specific, Spring Web MVC Controllers to interact with the HttpSession as needed by your application:

Application Controller using HttpSession. 

@Controller
class MyApplicationController {

  @GetRequest(...)
  public String processGet(HttpSession session) {
    // interact with HttpSession
  }
}

The HttpSession is replaced by a Spring managed Session that will be stored in either Apache Geode or Pivotal GemFire, or even Pivotal Cloud Cache.

By default, Spring Boot for Apache Geode & Pivotal GemFire (SBDG) applies reasonable and sensible defaults when configuring Apache Geode or Pivotal GemFire as the provider in Spring Session.

So, for instance, by default, SBDG set the session expiration timeout to 30 minutes. It also uses a ClientRegionShortcut.PROXY as the client Region data management policy for the Apache Geode/Pivotal GemFire Region managing the (HTTP) Session state when the Spring Boot application is using a ClientCache, which it does by default.

However, what if the defaults are not sufficient for your application requirements?

There may be cases where you do not want your Spring Boot application to manage (HTTP) Session state using either Apache Geode or Pivotal GemFire. In certain cases, you may be using another Spring Session provider, such as Redis, to cache and manage your Spring Boot application’s (HTTP) Session state, while, even in other cases, you do not want to use Spring Session to manage your (HTTP) Session state at all. Rather, you prefer to use your Web Server’s (e.g. Tomcat) HttpSession state management.

Either way, you can specifically call out your Spring Session provider using the spring.session.store-type property in application.properties, as follows:

Use Redis as the Spring Session Provider. 

#application.properties

spring.session.store-type=redis
...

If you prefer not to use Spring Session to manage your Spring Boot application’s (HTTP) Session state at all, then do the following:

Use Web Server Session State Management. 

#application.properties

spring.session.store-type=none
...

Again, see Spring Boot docs for more details.

Whether you are using Spring Session in a Spring Boot ClientCache application connecting to an externally managed cluster of Apache Geode or Pivotal GemFire servers, or connecting to a cluster of servers in a Pivotal Cloud Cache instance managed by a Pivotal Platform environment, the setup is the same.

Spring Session for Apache Geode, Pivotal GemFire, and Pivotal Cloud Cache (PCC) expects there to exist a cache Region in the cluster that will store and manage the (HTTP) Session state when your Spring Boot application is a ClientCache application in a client/server topology.

By default, the cache Region used to store and manage (HTTP) Session state is called "ClusteredSpringSessions".

You can set the name of the cache Region used to store and manage (HTTP) Session state either by explicitly declaring the @EnableGemFireHttpSession annotation on your main @SpringBootApplication class, like so:

Using `@EnableGemfireHttpSession. 

@SpringBootApplication
@EnableGemFireHttpSession(regionName = "MySessions")
class MySpringBootSpringSessionApplication { ... }

Or alternatively, we recommend users to configure the cache Region name using the well-known and documented property in Spring Boot application.properties:

Using properties. 

spring.session.data.gemfire.session.region.name=MySessions

Once you decide on the cache Region name used to store and manage (HTTP) Sessions, you must create the Region in the cluster somehow.

On the client, this is simple since SBDG’s auto-configuration will automatically create the client PROXY Region used to send/receive (HTTP) Session state between the client and server for you, when either Spring Session is on the application classpath (e.g. spring-geode-starter-session), or you explicitly declare the @EnableGemFireHttpSession annotation on your main @SpringBootApplication class.

However, on the server-side, you currently have a couple of options.

First, you can create the cache Region manually using Gfsh, like so:

Create the Sessions Region using Gfsh. 

gfsh> create region --name=MySessions --type=PARTITION --entry-idle-time-expiration=1800
        --entry-idle-time-expiration-action=INVALIDATE

You must create the cache Region with the appropriate name and an expiration policy.

In this case, we created an Idle Expiration Policy with a timeout of 1800 seconds (30 minutes), after which, the entry (i.e. Session object) will be "invalidated".

Alternatively, you could send the definition for the cache Region from your Spring Boot ClientCache application to the cluster using the SBDG @EnableClusterAware annotation, which is meta-annotated with SDG’s @EnableClusterConfiguration annotation.

Using @EnableClusterAware. 

@SpringBootApplication
@EnableClusterAware
class MySpringBootSpringSessionApplication { ... }

However, it is not currently possible to send Expiration Policy configuration metadata to the cluster yet. Therefore, you must manually alter the cache Region to set the Expiration Policy, like so:

Using Gfsh to Alter Region. 

gfsh> alter region --name=MySessions --entry-idle-time-expiration=1800
        --entry-idle-time-expiration-action=INVALIDATE

That is it!

Now your Spring Boot ClientCache application using Spring Session in a client/server topology is configured to store and manage user (HTTP) Session state in the cluster. This works for either standalone, externally managed Apache Geode or Pivotal GemFire clusters, or when using PCC running in a Pivotal Platform environment.