14. Spring Session

This section covers auto-configuration of Spring Session using either Apache Geode or Pivotal GemFire to manage (HTTP) Session state in a reliable (consistent), highly-available (replicated) and clustered manner.

Spring Session provides an API and several implementations for managing a user’s session information. It has the ability to replace the javax.servlet.http.HttpSession in an application container neutral way along with proving Session IDs in HTTP headers to work with RESTful APIs.

Furthermore, Spring Session provides the ability to keep the HttpSession alive even when working with WebSockets and reactive Spring WebFlux WebSessions.

A full discussion of Spring Session is beyond the scope of this document, and the reader is encouraged to learn more by reading the docs and reviewing the samples.

Of course, Spring Boot for Apache Geode & Pivotal GemFire adds auto-configuration support to configure either Apache Geode or Pivotal GemFire as the user’s session information management provider when Spring Session for Apache Geode or Pivotal GemFire is on your Spring Boot application’s classpath.

[Tip]Tip

You can learn more about Spring Session for Apache Geode/Pivotal GemFire in the docs.

14.1 Configuration

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.1.12.RELEASE</version>
  </dependency>

[Tip]Tip

You may replace Apache Geode with Pivotal GemFire simply by changing the artifact from spring-session-data-geode to spring-session-data-gemfire. The version number is the same.

Then, begin your Spring Boot application as you normally would:

Spring Boot Application. 

@SpringBootApplication
public 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.

14.2 Custom Configuration

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?

14.2.1 Custom Configuration using Properties

Spring Session for Apache Geode/Pivotal GemFire publishes well-known configuration properties for each of the various Spring Session configuration options when using Apache Geode or Pivotal GemFire as the (HTTP) Session state management provider.

You may specify any of these properties in a Spring Boot application.properties file to adjust Spring Session’s configuration when using Apache Geode or Pivotal GemFire.

In addition to the properties provided in and by Spring Session for Apache Geode/Pivotal GemFire, Spring Boot for Apache Geode/Pivotal GemFire also recognizes and respects the spring.session.timeout property as well as the server.servlet.session.timeout property as discussed here.

[Tip]Tip

spring.session.data.gemfire.session.expiration.max-inactive-interval-seconds takes precedence over spring.session.timeout, which takes precedence over server.servlet.session.timeout, when any combination of these properties have been simultaneously configured in the Spring Environment of your application.

14.2.2 Custom Configuration using a Configurer

Spring Session for Apache Geode/Pivotal GemFire also provides the SpringSessionGemFireConfigurer callback interface, which can be declared in your Spring ApplicationContext to programmatically control the configuration of Spring Session when using Apache Geode or Pivotal GemFire.

The SpringSessionGemFireConfigurer, when declared in the Spring ApplicationContext, takes precedence over any of the Spring Session (for Apache Geode/Pivotal GemFire) configuration properties, and will effectively override them when both are present.

More information on using the SpringSessionGemFireConfigurer can be found in the docs.

14.3 Disabling Session State Caching

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.

[Tip]Tip

It is possible to include multiple providers on the classpath of your Spring Boot application. For instance, you might be using Redis to cache your application’s (HTTP) Session state while using either Apache Geode or Pivotal GemFire as your application’s persistent store (System of Record).

[Note]Note

Spring Boot does not properly recognize spring.session.store-type=[gemfire|geode] even though Spring Boot for Apache Geode/Pivotal GemFire is setup to handle either of these property values (i.e. either “gemfire” or “geode”).