Spring Session

Spring Session provides an API and implementations for managing a user’s session information.

Introduction

Spring Session provides an API and implementations for managing a user’s session information. It also provides transparent integration with:

HttpSession - allows replacing the HttpSession in an application container (i.e. Tomcat) neutral way. Additional features include:
- Clustered Sessions - Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution.
- Multiple Browser Sessions - Spring Session supports managing multiple users' sessions in a single browser instance (i.e. multiple authenticated accounts similar to Google).
- RESTful APIs - Spring Session allows providing session ids in headers to work with RESTful APIs
WebSocket - provides the ability to keep the HttpSession alive when receiving WebSocket messages

Samples and Guides (Start Here)

If you are looking to get started with Spring Session, the best place to start is our Sample Applications.

Table 1. Sample Applications
Source	Description	Guide
HttpSession	Demonstrates how to use Spring Session to replace the `HttpSession` with a Redis store.	HttpSession Guide
HttpSession XML	Demonstrates how to use Spring Session to replace the `HttpSession` with a Redis store using XML based configuration.	HttpSession XML Guide
Spring Boot	Demonstrates how to use Spring Session with Spring Boot.	Spring Boot Guide
Spring Security	Demonstrates how to use Spring Session with an existing Spring Security application.	Spring Security Guide
REST	Demonstrates how to use Spring Session in a REST application to support authenticating with a header.	REST Guide
Multiple Users	Demonstrates how to use Spring Session to manage multiple simultaneous browser sessions (i.e Google Accounts).	Manage Multiple Users Guide
WebSocket	Demonstrates how to use Spring Session with WebSockets.	WebSocket Guide
Hazelcast	Demonstrates how to use Spring Session with Hazelcast.	TBD

HttpSession Integration

Spring Session provides transparent integration with HttpSession. This means that developers can switch the HttpSession implementation out with an implementation that is backed by Spring Session.

Why Spring Session & HttpSession?

We have already mentioned that Spring Session provides transparent integration with HttpSession, but what benefits do we get out of this?

Clustered Sessions - Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution.
Multiple Browser Sessions - Spring Session supports managing multiple users' sessions in a single browser instance (i.e. multiple authenticated accounts similar to Google).
RESTful APIs - Spring Session allows providing session ids in headers to work with RESTful APIs

HttpSession with Redis

Using Spring Session with HttpSession is enabled by adding a Servlet Filter before anything that uses the HttpSession. You can choose from enabling this using either:

Java Based Configuration
XML Based Configuration

Redis Java Based Configuration

This section describes how to use Redis to back HttpSession using Java based configuration.

The HttpSession Sample provides a working sample on how to integrate Spring Session and HttpSession using XML configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession Guide when integrating with your own application.

Spring Java Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

@EnableRedisHttpSession (1)
public class Config {

        @Bean
        public JedisConnectionFactory connectionFactory() {
                return new JedisConnectionFactory(); (2)
        }
}

1	The `@EnableRedisHttpSession` annotation creates a Spring Bean with the name of `springSessionRepositoryFilter` that implements Filter. The filter is what is in charge of replacing the `HttpSession` implementation to be backed by Spring Session. In this instance Spring Session is backed by Redis.
2	We create a `RedisConnectionFactory` that connects Spring Session to the Redis Server. We configure the connection to connect to localhost on the default port (6379) For more information on configuring Spring Data Redis, refer to the reference documentation.

Java Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, Spring needs to load our Config class. Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer both of these steps extremely easy. You can find an example below:

src/main/java/sample/Initializer.java

public class Initializer
                extends AbstractHttpSessionApplicationInitializer { (1)

        public Initializer() {
                super(Config.class); (2)
        }
}

The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.

1	The first step is to extend `AbstractHttpSessionApplicationInitializer`. This ensures that the Spring Bean by the name `springSessionRepositoryFilter` is registered with our Servlet Container for every request.
2	`AbstractHttpSessionApplicationInitializer` also provides a mechanism to easily ensure Spring loads our `Config`.

Redis XML Based Configuration

This section describes how to use Redis to back HttpSession using XML based configuration.

The HttpSession XML Sample provides a working sample on how to integrate Spring Session and HttpSession using XML configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession XML Guide when integrating with your own application.

Spring XML Configuration

src/main/webapp/WEB-INF/spring/session.xml

(1)
<context:annotation-config/>
<bean class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration"/>

(2)
<bean class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"/>

1 We use the combination of <context:annotation-config/> and RedisHttpSessionConfiguration because Spring Session does not yet provide XML Namespace support (see gh-104). This creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by Redis.

2 We create a RedisConnectionFactory that connects Spring Session to the Redis Server. We configure the connection to connect to localhost on the default port (6379) For more information on configuring Spring Data Redis, refer to the reference documentation.

XML Servlet Container Initialization

In order for our Filter to do its magic, we need to instruct Spring to load our session.xml configuration. We do this with the following configuration:

src/main/webapp/WEB-INF/web.xml

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/*.xml
    </param-value>
</context-param>
<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

The ContextLoaderListener reads the contextConfigLocation and picks up our session.xml configuration.

Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. The following snippet performs this last step for us:

src/main/webapp/WEB-INF/web.xml

<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

The DelegatingFilterProxy will look up a Bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every request that DelegatingFilterProxy is invoked, the springSessionRepositoryFilter will be invoked.

How HttpSession Integration Works

Fortunately both HttpSession and HttpServletRequest (the API for obtaining an HttpSession) are both interfaces. This means that we can provide our own implementations for each of these APIs.

This section describes how Spring Session provides transparent integration with HttpSession. The intent is so that user’s can understand what is happening under the covers. This functionality is already integrated and you do NOT need to implement this logic yourself.

First we create a custom HttpServletRequest that returns a custom implementation of HttpSession. It looks something like the following:

public class SessionRepositoryRequestWrapper extends HttpServletRequestWrapper {

        public SessionRepositoryRequestWrapper(HttpServletRequest original) {
                super(original);
        }

        public HttpSession getSession() {
                return getSession(true);
        }

        public HttpSession getSession(boolean createNew) {
                // create an HttpSession implementation from Spring Session
        }

        // ... other methods delegate to the original HttpServletRequest ...
}

Any method that returns an HttpSession is overridden. All other methods are implemented by HttpServletRequestWrapper and simply delegate to the original HttpServletRequest implementation.

We replace the HttpServletRequest implementation using a servlet Filter called SessionRepositoryFilter. The pseudocode can be found below:

public class SessionRepositoryFilter implements Filter {

        public doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
                HttpServletRequest httpRequest = (HttpServletRequest) request;
                SessionRepositoryRequestWrapper customRequest =
                        new SessionRepositoryRequestWrapper(httpRequest);

                chain.doFilter(customRequest, response, chain);
        }

        // ...
}

By passing in a custom HttpServletRequest implementation into the FilterChain we ensure that anything invoked after our Filter uses the custom HttpSession implementation. This highlights why it is important that Spring Session’s SessionRepositoryFilter must be placed before anything that interacts with the HttpSession.

Multiple HttpSessions in Single Browser

Spring Session has the ability to support multiple sessions in a single browser instance. This provides the ability to support authenticating with multiple users in the same browser instance (i.e. Google Accounts).

The Manage Multiple Users Guide provides a complete working example of managing multiple users in the same browser instance. You can follow the basic steps for integration below, but you are encouraged to follow along with the detailed Manage Multiple Users Guide when integrating with your own application.

Let’s take a look at how Spring Session keeps track of multiple sessions.

Managing a Single Session

Spring Session keeps track of the HttpSession by adding a value to a cookie named SESSION. For example, the SESSION cookie might have a value of:

7e8383a4-082c-4ffe-a4bc-c40fd3363c5e

Adding a Session

We can add another session by requesting a URL that contains a special parameter in it. By default the parameter name is _s. For example, the following URL would create a new session:

http://localhost:8080/?_s=1

The parameter value does not indicate the actual session id. This is important because we never want to allow the session id to be determined by a client to avoid session fixation attacks. Additionally, we do not want the session id to be leaked since it is sent as a query parameter. Remember sensitive information should only be transmitted as a header or in the body of the request.

Rather than creating the URL ourselves, we can utilize the HttpSessionManager to do this for us. We can obtain the HttpSessionManager from the HttpServletRequest using the following:

src/main/java/sample/UserAccountsFilter.java

HttpSessionManager sessionManager =
        (HttpSessionManager) httpRequest.getAttribute(HttpSessionManager.class.getName());

We can now use it to create a URL to add another session.

src/main/java/sample/UserAccountsFilter.java

String addAlias = unauthenticatedAlias == null ? (1)
        sessionManager.getNewSessionAlias(httpRequest) : (2)
        unauthenticatedAlias; (3)
String addAccountUrl = sessionManager.encodeURL(contextPath, addAlias); (4)

1	We have an existing variable named `unauthenticatedAlias`. The value is an alias that points to an existing unauthenticated session. If no such session exists, the value is null. This ensures if we have an existing unauthenticated session that we use it instead of creating a new session.
2	If all of our sessions are already associated to a user, we create a new session alias.
3	If there is an existing session that is not associated to a user, we use its session alias.
4	Finally, we create the add account URL. The URL contains a session alias that either points to an existing unauthenticated session or is an alias that is unused thus signaling to create a new session associated to that alias.

Now our SESSION cookie looks something like this:

0 7e8383a4-082c-4ffe-a4bc-c40fd3363c5e 1 1d526d4a-c462-45a4-93d9-84a39b6d44ad

Such that:

There is a session with the id 7e8383a4-082c-4ffe-a4bc-c40fd3363c5e
- The alias for this session is 0. For example, if the URL is http://localhost:8080/?_s=0 this alias would be used.
- This is the default session. This means that if no session alias is specified, then this session is used. For example, if the URL is http://localhost:8080/ this session would be used.
There is a session with the id 1d526d4a-c462-45a4-93d9-84a39b6d44ad
- The alias for this session is 1. If the session alias is 1, then this session is used. For example, if the URL is http://localhost:8080/?_s=1 this alias would be used.

Automatic Session Alias Inclusion with encodeURL

The nice thing about specifying the session alias in the URL is that we can have multiple tabs open with different active sessions. The bad thing is that we need to include the session alias in every URL of our application. Fortunately, Spring Session will automatically include the session alias in any URL that passes through HttpServletResponse#encodeURL(java.lang.String)

This means that if you are using standard tag libraries the session alias is automatically included in the URL. For example, if we are currently using the session with the alias of 1, then the following:

src/main/webapp/index.jsp

  -->
<c:url value="/link.jsp" var="linkUrl"/>
<a id="navLink" href="${linkUrl}">Link</a>

will output a link of:

<a id="navLink" href="/link.jsp?_s=1">Link</a>

HttpSession & RESTful APIs

Spring Session can work with RESTful APIs by allowing the session to be provided in a header.

The REST Sample provides a working sample on how to use Spring Session in a REST application to support authenticating with a header. You can follow the basic steps for integration below, but you are encouraged to follow along with the detailed REST Guide when integrating with your own application.

Spring Configuration

@Configuration
@EnableRedisHttpSession (1)
public class HttpSessionConfig {

        @Bean
        public JedisConnectionFactory connectionFactory() {
                return new JedisConnectionFactory();  (2)
        }

        @Bean
        public HttpSessionStrategy httpSessionStrategy() {
                return new HeaderHttpSessionStrategy(); (3)
        }
}

1	The `@EnableRedisHttpSession` annotation creates a Spring Bean with the name of `springSessionRepositoryFilter` that implements `Filter`. The filter is what is in charge of replacing the `HttpSession` implementation to be backed by Spring Session. In this instance Spring Session is backed by Redis.
2	We create a `RedisConnectionFactory` that connects Spring Session to the Redis Server. We configure the connection to connect to localhost on the default port (6379) For more information on configuring Spring Data Redis, refer to the reference documentation.
3	We customize Spring Session’s HttpSession integration to use HTTP headers to convey the current session information instead of cookies.

Servlet Container Initialization

In order for our Filter to do its magic, Spring needs to load our Config class. We provide the configuration in our Spring MvcInitializer as shown below:

src/main/java/sample/mvc/MvcInitializer.java

@Override
protected Class<?>[] getRootConfigClasses() {
    return new Class[] {SecurityConfig.class, HttpSessionConfig.class};
}

Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer that makes this extremely easy. Simply extend the class with the default constructor as shown below:

src/main/java/sample/Initializer.java

public class Initializer extends AbstractHttpSessionApplicationInitializer {

}

The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.

WebSocket Integration

Spring Session provides transparent integration with Spring’s WebSocket support.

Spring Session’s WebSocket support only works with Spring’s WebSocket support. Specifically it does not work with using JSR-356 directly. This is due to the fact that JSR-356 does not have a mechanism for intercepting incoming WebSocket messages.

Why Spring Session & WebSockets?

So why do we need Spring Session when using WebSockets?

Consider an email application that does much of its work through HTTP requests. However, there is also a chat application embedded within it that works over WebSocket APIs. If a user is actively chatting with someone, we should not timeout the HttpSession since this would be pretty poor user experience. However, this is exactly what JSR-356 does.

Another issue is that according to JSR-356 if the HttpSession times out any WebSocket that was created with that HttpSession and an authenticated user should be forcibly closed. This means that if we are actively chatting in our application and are not using the HttpSession, then we will also disconnect from our conversation!

WebSocket Usage

The WebSocket Sample provides a working sample on how to integrate Spring Session with WebSockets. You can follow the basic steps for integration below, but you are encouraged to follow along with the detailed WebSocket Guide when integrating with your own application:

HttpSession Integration

Before using WebSocket integration, you should be sure that you have HttpSession Integration working first.

Spring Configuration

In a typical Spring WebSocket application users would extend AbstractWebSocketMessageBrokerConfigurer. For example, the configuration might look something like the following:

@Configuration
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebSocketConfig
                extends AbstractWebSocketMessageBrokerConfigurer {

        public void registerStompEndpoints(StompEndpointRegistry registry) {
                registry.addEndpoint("/messages")
                                .withSockJS();
        }

        @Override
        public void configureMessageBroker(MessageBrokerRegistry registry) {
                registry.enableSimpleBroker("/queue/", "/topic/");
                registry.setApplicationDestinationPrefixes("/app");
        }
}

We can easily update our configuration to use Spring Session’s WebSocket support. For example:

src/main/java/samples/config/WebSocketConfig.java

@Configuration
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebSocketConfig
          extends AbstractSessionWebSocketMessageBrokerConfigurer<ExpiringSession> { (1)

        protected void configureStompEndpoints(StompEndpointRegistry registry) { (2)
                registry.addEndpoint("/messages")
                                .withSockJS();
        }

        public void configureMessageBroker(MessageBrokerRegistry registry) {
                registry.enableSimpleBroker("/queue/", "/topic/");
                registry.setApplicationDestinationPrefixes("/app");
        }
}

To hook in the Spring Session support we only need to change two things:

1	Instead of extending `AbstractWebSocketMessageBrokerConfigurer` we extend `AbstractSessionWebSocketMessageBrokerConfigurer`
2	We rename the `registerStompEndpoints` method to `configureStompEndpoints`

What does AbstractSessionWebSocketMessageBrokerConfigurer do behind the scenes?

WebSocketConnectHandlerDecoratorFactory is added as a WebSocketHandlerDecoratorFactory to WebSocketTransportRegistration. This ensures a custom SessionConnectEvent is fired that contains the WebSocketSession. The WebSocketSession is necessary to terminate any WebSocket connections that are still open when a Spring Session is terminated.
SessionRepositoryMessageInterceptor is added as a HandshakeInterceptor to every StompWebSocketEndpointRegistration. This ensures that the Session is added to the WebSocket properties to enable updating the last accessed time.
SessionRepositoryMessageInterceptor is added as a ChannelInterceptor to our inbound ChannelRegistration. This ensures that every time an inbound message is received, that the last accessed time of our Spring Session is updated.
WebSocketRegistryListener is created as a Spring Bean. This ensures that we have a mapping of all of the Session id to the corresponding WebSocket connections. By maintaining this mapping, we can close all the WebSocket connections when a Spring Session (HttpSession) is terminated.

API Documentation

You can browse the complete Javadoc online. The key APIs are described below:

Session

A Session is a simplified Map of name value pairs.

Typical usage might look like the following:

public class RepositoryDemo<S extends Session> {
    private SessionRepository<S> repository; (1)

    public void demo() {
        S toSave = repository.createSession(); (2)

        (3)
        User rwinch = new User("rwinch");
        toSave.setAttribute(ATTR_USER, rwinch);

        repository.save(toSave); (4)

        S session = repository.getSession(toSave.getId()); (5)

        (6)
        User user = session.getAttribute(ATTR_USER);
        assertThat(user).isEqualTo(rwinch);
    }

    // ... setter methods ...
}

1	We create a `SessionRepository` instance with a generic type, `S`, that extends `Session`. The generic type is defined in our class.
2	We create a new `Session` using our `SessionRepository` and assign it to a variable of type `S`.
3	We interact with the `Session`. In our example, we demonstrate saving a `User` to the `Session`.
4	We now save the `Session`. This is why we needed the generic type `S`. The `SessionRepository` only allows saving `Session` instances that were created or retrieved using the same `SessionRepository`. This allows for the `SessionRepository` to make implementation specific optimizations (i.e. only writing attributes that have changed).
5	We retrieve the `Session` from the `SessionRepository`.
6	We obtain the persisted `User` from our `Session` without the need for explicitly casting our attribute.

ExpiringSession

An ExpiringSession extends a Session by providing attributes related to the Session instance’s expiration. If there is no need to interact with the expiration information, prefer using the more simple Session API.

Typical usage might look like the following:

public class ExpiringRepositoryDemo<S extends ExpiringSession> {
    private SessionRepository<S> repository; (1)

    public void demo() {
        S toSave = repository.createSession(); (2)
        // ...
        toSave.setMaxInactiveIntervalInSeconds(30); (3)

        repository.save(toSave); (4)

        S session = repository.getSession(toSave.getId()); (5)
        // ...
    }

    // ... setter methods ...
}

1	We create a `SessionRepository` instance with a generic type, `S`, that extends `ExpiringSession`. The generic type is defined in our class.
2	We create a new `ExpiringSession` using our `SessionRepository` and assign it to a variable of type `S`.
3	We interact with the `ExpiringSession`. In our example, we demonstrate updating the amount of time the `ExpiringSession` can be inactive before it expires.
4	We now save the `ExpiringSession`. This is why we needed the generic type `S`. The `SessionRepository` only allows saving `ExpiringSession` instances that were created or retrieved using the same `SessionRepository`. This allows for the `SessionRepository` to make implementation specific optimizations (i.e. only writing attributes that have changed). The last accessed time is automatically updated when the `ExpiringSession` is saved.
5	We retrieve the `ExpiringSession` from the `SessionRepository`. If the `ExpiringSession` were expired, the result would be null.

SessionRepository

A SessionRepository is in charge of creating, retrieving, and persisting Session instances.

If possible, developers should not interact directly with a SessionRepository or a Session. Instead, developers should prefer interacting with SessionRepository and Session indirectly through the HttpSession and WebSocket integration.

RedisOperationsSessionRepository

RedisOperationsSessionRepository is a SessionRepository that is implemented using Spring Data’s RedisOperations. In a web environment, this is typically used in combination with SessionRepositoryFilter. The implementation supports SessionDestroyedEvent through SessionMessageListener.

Instantiating a RedisOperationsSessionRepository

A typical example of how to create a new instance can be seen below:

JedisConnectionFactory factory = new JedisConnectionFactory();
SessionRepository<? extends ExpiringSession> repository =
        new RedisOperationsSessionRepository(factory);

For additional information on how to create a RedisConnectionFactory, refer to the Spring Data Redis Reference.

Storage Details

Each session is stored in Redis as a Hash. Each session is set and updated using the HMSET command. An example of how each session is stored can be seen below.

HMSET spring:session:sessions:<session-id> creationTime 1404360000000 \
    maxInactiveInterval 1800 lastAccessedTime 1404360000000 \
    sessionAttr:<attrName> someAttrValue sessionAttr:<attrName2> someAttrValue2

Session Expiration

An expiration is associated to each session using the EXPIRE command based upon the RedisOperationsSessionRepository.RedisSession.getMaxInactiveInterval(). For example:

EXPIRE spring:session:sessions:<session-id> 1800

Spring Session relies on the expired and delete keyspace notifications from Redis to fire a SessionDestroyedEvent. It is the SessionDestroyedEvent that ensures resources associated with the Session are cleaned up. For example, when using Spring Session’s WebSocket support the Redis expired or delete event is what triggers any WebSocket connections associated with the session to be closed.

One problem with this approach is that Redis makes no guarantee of when the expired event will be fired if they key has not been accessed. Specifically the background task that Redis uses to clean up expired keys is a low priority task and may not trigger the key expiration. For additional details see Timing of expired events section in the Redis documentation.

To circumvent the fact that expired events are not guaranteed to happen we can ensure that each key is accessed when it is expected to expire. This means that if the TTL is expired on the key, Redis will remove the key and fire the expired event when we try to access they key.

For this reason, each session expiration is also tracked to the nearest minute. This allows a background task to access the potentially expired sessions to ensure that Redis expired events are fired in a more deterministic fashion. For example:

SADD spring:session:expirations:<expire-rounded-up-to-nearest-minute> <session-id> EXPIRE spring:session:expirations:<expire-rounded-up-to-nearest-minute> 1860

The background task will then use these mappings to explicitly request each key. By accessing they key, rather than deleting it, we ensure that Redis deletes the key for us only if the TTL is expired.

We do not explicitly delete the keys since in some instances there may be a race condition that incorrectly identifies a key as expired when it is not. Short of using distributed locks (which would kill our performance) there is no way to ensure the consistency of the expiration mapping. By simply accessing the key, we ensure that the key is only removed if the TTL on that key is expired.

Optimized Writes

The Session instances managed by RedisOperationsSessionRepository keeps track of the properties that have changed and only updates those. This means if an attribute is written once and read many times we only need to write that attribute once. For example, assume the session attribute "sessionAttr2" from earlier was updated. The following would be executed upon saving:

HMSET spring:session:sessions:<session-id> sessionAttr:<attrName2> newValue EXPIRE spring:session:sessions:<session-id> 1800

SessionDestroyedEvent

RedisOperationsSessionRepository supports firing a SessionDestroyedEvent whenever a Session is deleted or when it expires. This is necessary to ensure resources associated with the Session are properly cleaned up. For example, when integrating with WebSockets the SessionDestroyedEvent is in charge of closing any active WebSocket connections.

Firing a SessionDestroyedEvent is made available through the SessionMessageListener which listens to Redis Keyspace events. In order for this to work, Redis Keyspace events for Generic commands and Expired events needs to be enabled. For example:

redis-cli config set notify-keyspace-events Egx

If you are using @EnableRedisHttpSession the SessionMessageListener and enabling the necessary Redis Keyspace events is done automatically. However, in a secured Redis enviornment the config command is disabled. This means that Spring Session cannot configure Redis Keyspace events for you. To disable the automatic configuration add ConfigureRedisAction.NO_OP as a bean.

For example, Java Configuration can use the following:

@Bean
public static ConfigureRedisAction configureRedisAction() {
    return ConfigureRedisAction.NO_OP;
}

XML Configuraiton can use the following:

<util:constant
    static-field="org.springframework.session.data.redis.config.ConfigureRedisAction.NO_OP"/>

Viewing the Session in Redis

After installing redis-cli, you can inspect the values in Redis using the redis-cli. For example, enter the following into a terminal:

$ redis-cli
redis 127.0.0.1:6379> keys *
1) "spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021" (1)
2) "spring:session:expirations:1418772300000" (2)

1	The suffix of this key is the session identifier of the Spring Session.
2	This key contains all the session ids that should be deleted at the time `1418772300000`.

You can also view the attributes of each session.

redis 127.0.0.1:6379> hkeys spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021
1) "lastAccessedTime"
2) "creationTime"
3) "maxInactiveInterval"
4) "sessionAttr:username"
redis 127.0.0.1:6379> hget spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021 sessionAttr:username
"\xac\xed\x00\x05t\x00\x03rob"

MapSessionRepository

The MapSessionRepository allows for persisting ExpiringSession in a Map with the key being the ExpiringSession id and the value being the ExpiringSession. The implementation can be used with a ConcurrentHashMap as a testing or convenience mechanism. Alternatively, it can be used with distributed Map implementations. For example, it can be used with Hazelcast.

Instantiating MapSessionRepository

Creating a new instance is as simple as:

SessionRepository<? extends ExpiringSession> repository = new MapSessionRepository();

Using Spring Session and Hazlecast

The Hazelcast Sample is a complete application demonstrating using Spring Session with Hazelcast. To run it use the following:

./gradlew :samples:hazelcast:tomcatRun

Spring Session Community

We are glad to consider you a part of our community. Please find additional information below.

Support

You can get help by asking questions on StackOverflow with the tag spring-session. Similarly we encourage helping others by answering questions on StackOverflow.

Source Code

Our source code can be found on github at https://github.com/spring-projects/spring-session/

Issue Tracking

We track issues in github issues at https://github.com/spring-projects/spring-session/issues

Contributing

We appreciate Pull Requests.

License

Spring Session is Open Source software released under the Apache 2.0 license.

Minimum Requirements

The minimum requirements for Spring Session are:

Java 5+
If you are running in a Servlet Container (not required), Servlet 2.5+
If you are using other Spring libraries (not required), the minimum required version is Spring 3.2.14. While we re-run all unit tests against Spring 3.2.x, we recommend using the latest Spring 4.x version when possible.
@EnableRedisHttpSession requires Redis 2.8+. This is necessary to support Session Expiration

At its core Spring Session only has a required dependency on commons-logging. For an example of using Spring Session without any other Spring dependencies, refer to the hazelcast sample application.