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

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

5.2.1 Redis Java-based Configuration

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

	Note
	The HttpSession Sample provides a working sample of how to integrate Spring Session and HttpSession by using Java configuration. You can read the basic steps for integration in the next few sections, but we encourage you 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. To do so, add the following Spring Configuration:

@EnableRedisHttpSession 
public class Config {

	@Bean
	public LettuceConnectionFactory connectionFactory() {
		return new LettuceConnectionFactory(); 
	}
}

	The @EnableRedisHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance, Spring Session is backed by Redis.
	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, see 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 (that is, Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer to make both of these steps easy. The following shows an example:

src/main/java/sample/Initializer.java. 

public class Initializer extends AbstractHttpSessionApplicationInitializer { 

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

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

	The first step is to extend AbstractHttpSessionApplicationInitializer. Doing so ensures that the Spring Bean by the name of springSessionRepositoryFilter is registered with our Servlet Container for every request.
	AbstractHttpSessionApplicationInitializer also provides a mechanism to ensure Spring loads our Config.

5.2.2 Redis XML-based Configuration

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

	Note
	The HttpSession XML Sample provides a working sample of how to integrate Spring Session and HttpSession using XML configuration. You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession XML Guide when integrating with your own application.

Spring XML 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. To do so, add the following Spring Configuration:

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

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


<bean class="org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory"/>

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 in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance, Spring Session is backed by Redis.

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, see the reference documentation.

XML 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, we need to instruct Spring to load our session.xml configuration. We can do so 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 (that is, 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>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

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

You can use Spring Session with HttpSession by adding a servlet filter before anything that uses the HttpSession. You can choose to do in any of the following ways:

5.3.1 JDBC Java-based Configuration

This section describes how to use a relational database to back HttpSession when you use Java-based configuration.

	Note
	The HttpSession JDBC Sample provides a working sample of how to integrate Spring Session and HttpSession by using Java configuration. You can read the basic steps for integration in the next few sections, but we encouraged you to follow along with the detailed HttpSession JDBC 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. To do so, add the following Spring Configuration:

@EnableJdbcHttpSession 
public class Config {

	@Bean
	public EmbeddedDatabase dataSource() {
		return new EmbeddedDatabaseBuilder() 
				.setType(EmbeddedDatabaseType.H2)
				.addScript("org/springframework/session/jdbc/schema-h2.sql").build();
	}

	@Bean
	public PlatformTransactionManager transactionManager(DataSource dataSource) {
		return new DataSourceTransactionManager(dataSource); 
	}

}

	The @EnableJdbcHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter. That bean implements Filter. The filter is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance, Spring Session is backed by a relational database.
	We create a dataSource that connects Spring Session to an embedded instance of an H2 database. We configure the H2 database to create database tables by using the SQL script that is included in Spring Session.
	We create a transactionManager that manages transactions for previously configured dataSource.

For additional information on how to configure data access related concerns, see the Spring Framework 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 (that is, Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer to make both of these steps easy. The following example shows how to do so:

src/main/java/sample/Initializer.java. 

public class Initializer extends AbstractHttpSessionApplicationInitializer { 

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

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

	The first step is to extend AbstractHttpSessionApplicationInitializer. Doing so ensures that the Spring bean named springSessionRepositoryFilter is registered with our Servlet Container for every request.
	AbstractHttpSessionApplicationInitializer also provides a mechanism to ensure Spring loads our Config.

5.3.2 JDBC XML-based Configuration

This section describes how to use a relational database to back HttpSession when you use XML based configuration.

	Note
	The HttpSession JDBC XML Sample provides a working sample of how to integrate Spring Session and HttpSession by using XML configuration. You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession JDBC XML Guide when integrating with your own application.

Spring XML 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. The following listing shows how to add the following Spring Configuration:

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

<context:annotation-config/>
<bean class="org.springframework.session.jdbc.config.annotation.web.http.JdbcHttpSessionConfiguration"/>


<jdbc:embedded-database id="dataSource" database-name="testdb" type="H2">
	<jdbc:script location="classpath:org/springframework/session/jdbc/schema-h2.sql"/>
</jdbc:embedded-database>


<bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
	<constructor-arg ref="dataSource"/>
</bean>

	We use the combination of <context:annotation-config/> and JdbcHttpSessionConfiguration because Spring Session does not yet provide XML Namespace support (see gh-104). This creates a Spring bean with the name of springSessionRepositoryFilter. That bean implements Filter. The filter is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance, Spring Session is backed by a relational database.
	We create a dataSource that connects Spring Session to an embedded instance of an H2 database. We configure the H2 database to create database tables by using the SQL script that is included in Spring Session.
	We create a transactionManager that manages transactions for previously configured dataSource.

For additional information on how to configure data access-related concerns, see the Spring Framework Reference Documentation.

XML 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, we need to instruct Spring to load our session.xml configuration. We do so 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 (that is, 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>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

The DelegatingFilterProxy looks up a bean named springSessionRepositoryFilter and casts it to a Filter. For every request on which DelegatingFilterProxy is invoked, the springSessionRepositoryFilter is invoked.

5.3.3 JDBC Spring Boot-based Configuration

This section describes how to use a relational database to back HttpSession when you use Spring Boot.

	Note
	The HttpSession JDBC Spring Boot Sample provides a working sample of how to integrate Spring Session and HttpSession by using Spring Boot. You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession JDBC Spring Boot Guide when integrating with your own application.

Spring Boot Configuration

After adding the required dependencies, we can create our Spring Boot configuration. Thanks to first-class auto configuration support, setting up Spring Session backed by a relational database is as simple as adding a single configuration property to your application.properties. The following listing shows how to do so:

src/main/resources/application.properties. 

spring.session.store-type=jdbc # Session store type.

Under the hood, Spring Boot applies configuration that is equivalent to manually adding the @EnableJdbcHttpSession annotation. This creates a Spring bean with the name of springSessionRepositoryFilter. That bean implements Filter. The filter is in charge of replacing the HttpSession implementation to be backed by Spring Session.

You can further customize by using application.properties. The following listing shows how to do so:

src/main/resources/application.properties. 

server.servlet.session.timeout= # Session timeout. If a duration suffix is not specified, seconds are used.
spring.session.jdbc.initialize-schema=embedded # Database schema initialization mode.
spring.session.jdbc.schema=classpath:org/springframework/session/jdbc/schema-@@platform@@.sql # Path to the SQL file to use to initialize the database schema.
spring.session.jdbc.table-name=SPRING_SESSION # Name of the database table used to store sessions.

For more information, see the Spring Session portion of the Spring Boot documentation.

Configuring the DataSource

Spring Boot automatically creates a DataSource that connects Spring Session to an embedded instance of an H2 database. In a production environment, you need to update your configuration to point to your relational database. For example, you can include the following in your application.properties:

src/main/resources/application.properties. 

spring.datasource.url= # JDBC URL of the database.
spring.datasource.username= # Login username of the database.
spring.datasource.password= # Login password of the database.

For more information, see the Configure a DataSource portion of the Spring Boot documentation.

Servlet Container Initialization

Our Spring Boot 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 (that is, Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Boot takes care of both of these steps for us.

Using Spring Session with HttpSession is enabled by adding a Servlet Filter before anything that uses the HttpSession.

This section describes how to use Hazelcast to back HttpSession by using Java-based configuration.

	Note
	The Hazelcast Spring Sample provides a working sample of how to integrate Spring Session and HttpSession by using Java configuration. You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed Hazelcast Spring Guide when integrating with your own application.

@EnableHazelcastHttpSession 
@Configuration
public class HazelcastHttpSessionConfig {

	@Bean
	public HazelcastInstance hazelcastInstance() {
		MapAttributeConfig attributeConfig = new MapAttributeConfig()
				.setName(HazelcastSessionRepository.PRINCIPAL_NAME_ATTRIBUTE)
				.setExtractor(PrincipalNameExtractor.class.getName());

		Config config = new Config();

		config.getMapConfig(HazelcastSessionRepository.DEFAULT_SESSION_MAP_NAME) 
				.addMapAttributeConfig(attributeConfig)
				.addMapIndexConfig(new MapIndexConfig(
						HazelcastSessionRepository.PRINCIPAL_NAME_ATTRIBUTE, false));

		return Hazelcast.newHazelcastInstance(config); 
	}

}

5.4.2 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 SessionConfig class. Since our application is already loading Spring configuration by using our SecurityInitializer class, we can add our SessionConfig class to it. The following listing shows how to do so:

src/main/java/sample/SecurityInitializer.java. 

public class SecurityInitializer extends AbstractSecurityWebApplicationInitializer {

	public SecurityInitializer() {
		super(SecurityConfig.class, SessionConfig.class);
	}
}

Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our springSessionRepositoryFilter for every request. It is extremely important that Spring Session’s springSessionRepositoryFilter is invoked before Spring Security’s springSecurityFilterChain. Doing so ensures that the HttpSession that Spring Security uses is backed by Spring Session. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer that makes this doing so easy. The following example shows how to do so:

src/main/java/sample/Initializer.java. 

public class Initializer extends AbstractHttpSessionApplicationInitializer {

}

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

By extending AbstractHttpSessionApplicationInitializer, we ensure that the Spring Bean named springSessionRepositoryFilter is registered with our servlet container for every request before Spring Security’s springSecurityFilterChain.

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.

	Note
	This section describes how Spring Session provides transparent integration with HttpSession. We offer this content so that you 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 delegate to the original HttpServletRequest implementation.

We replace the HttpServletRequest implementation by using a servlet Filter called SessionRepositoryFilter. The pseudocode belows:

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 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 be placed before anything that interacts with the HttpSession.

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

	Note
	The REST Sample provides a working sample of how to use Spring Session in a REST application to support authenticating with a header. You can follow the basic steps for integration described in the next few sections, but we encourage you to follow along with the detailed REST Guide when integrating with your own application.

@Configuration
@EnableRedisHttpSession 
public class HttpSessionConfig {

	@Bean
	public LettuceConnectionFactory connectionFactory() {
		return new LettuceConnectionFactory(); 
	}

	@Bean
	public HttpSessionIdResolver httpSessionIdResolver() {
		return HeaderHttpSessionIdResolver.xAuthToken(); 
	}
}

5.6.2 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. We provide the configuration in our Spring MvcInitializer, as the following example shows:

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 (that is, Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer that makes doing so easy. To do so, extend the class with the default constructor, as the following example shows:

src/main/java/sample/Initializer.java. 

public class Initializer extends AbstractHttpSessionApplicationInitializer {

}

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

Spring Session supports HttpSessionListener by translating SessionDestroyedEvent and SessionCreatedEvent into HttpSessionEvent by declaring SessionEventHttpSessionListenerAdapter. To use this support, you need to:

If you use the configuration support documented in HttpSession with Redis, all you need to do is register every HttpSessionListener as a bean. For example, assume you want to support Spring Security’s concurrency control and need to use HttpSessionEventPublisher. In that case, you can add HttpSessionEventPublisher as a bean. In Java configuration, this might look like the following:

@Configuration
@EnableRedisHttpSession
public class RedisHttpSessionConfig {

	@Bean
	public HttpSessionEventPublisher httpSessionEventPublisher() {
		return new HttpSessionEventPublisher();
	}

	// ...
}

In XML configuration, this might look like the following:

<bean class="org.springframework.security.web.session.HttpSessionEventPublisher"/>

So why do we need Spring Session when we use 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 a 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, we also do disconnect from our conversation.

The WebSocket Sample provides a working sample of how to integrate Spring Session with WebSockets. You can follow the basic steps for integration described in the next few headings, but we encourage you to follow along with the detailed WebSocket Guide when integrating with your own application.

@Configuration
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

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

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

@Configuration
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebSocketConfig
		extends AbstractSessionWebSocketMessageBrokerConfigurer<Session> { 

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

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

We have already mentioned that Spring Session provides transparent integration with Spring WebFlux’s WebSession, but what benefits do we get out of this? As with HttpSession, Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution.

Using Spring Session with WebSession is enabled by registering a WebSessionManager implementation backed by Spring Session’s ReactiveSessionRepository. The Spring configuration is responsible for creating a WebSessionManager that replaces the WebSession implementation with an implementation backed by Spring Session. To do so, add the following Spring Configuration:

@EnableRedisWebSession 
public class SessionConfiguration {

	@Bean
	public LettuceConnectionFactory redisConnectionFactory() {
		return new LettuceConnectionFactory(); 
	}

}

It is considerably easier for Spring Session to integrate with Spring WebFlux and its WebSession, compared to Servlet API and its HttpSession. Spring WebFlux provides the WebSessionStore API, which presents a strategy for persisting WebSession.

	Note
	This section describes how Spring Session provides transparent integration with WebSession. We offer this content so that you 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 SpringSessionWebSession that delegates to Spring Session’s Session. It looks something like the following:

public class SpringSessionWebSession implements WebSession {

	enum State {
		NEW, STARTED
	}

	private final S session;

	private AtomicReference<State> state = new AtomicReference<>();

	SpringSessionWebSession(S session, State state) {
		this.session = session;
		this.state.set(state);
	}

	@Override
	public void start() {
		this.state.compareAndSet(State.NEW, State.STARTED);
	}

	@Override
	public boolean isStarted() {
		State value = this.state.get();
		return (State.STARTED.equals(value)
				|| (State.NEW.equals(value) && !this.session.getAttributes().isEmpty()));
	}

	@Override
	public Mono<Void> changeSessionId() {
		return Mono.defer(() -> {
			this.session.changeSessionId();
			return save();
		});
	}

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

Next, we create a custom WebSessionStore that delegates to the ReactiveSessionRepository and wraps Session into custom WebSession implementation, as the following listing shows:

public class SpringSessionWebSessionStore<S extends Session> implements WebSessionStore {

	private final ReactiveSessionRepository<S> sessions;

	public SpringSessionWebSessionStore(ReactiveSessionRepository<S> reactiveSessionRepository) {
		this.sessions = reactiveSessionRepository;
	}

	// ...
}

To be detected by Spring WebFlux, this custom WebSessionStore needs to be registered with ApplicationContext as a bean named webSessionManager. For additional information on Spring WebFlux, see the Spring Framework Reference Documentation.

Spring Session provides integration with Spring Security’s Remember-me Authentication. The support:

To configure Spring Session with Spring Security in Java Configuration, you can use the following listing as a guide:

@Override
protected void configure(HttpSecurity http) throws Exception {
	http
		// ... additional configuration ...
		.rememberMe()
			.rememberMeServices(rememberMeServices());
}

@Bean
public SpringSessionRememberMeServices rememberMeServices() {
	SpringSessionRememberMeServices rememberMeServices =
			new SpringSessionRememberMeServices();
	// optionally customize
	rememberMeServices.setAlwaysRemember(true);
	return rememberMeServices;
}

An XML-based configuration would look something like the following:

<security:http>
	<!-- ... -->
	<security:form-login />
	<security:remember-me services-ref="rememberMeServices"/>
</security:http>

<bean id="rememberMeServices"
	class="org.springframework.session.security.web.authentication.SpringSessionRememberMeServices"
	p:alwaysRemember="true"/>

Spring Session provides integration with Spring Security to support its concurrent session control. This allows limiting the number of active sessions that a single user can have concurrently, but, unlike the default Spring Security support, this also works in a clustered environment. This is done by providing a custom implementation of Spring Security’s SessionRegistry interface.

When using Spring Security’s Java config DSL, you can configure the custom SessionRegistry through the SessionManagementConfigurer, as the following listing shows:

@Configuration
public class SecurityConfiguration<S extends Session>
		extends WebSecurityConfigurerAdapter {

	@Autowired
	private FindByIndexNameSessionRepository<S> sessionRepository;

	@Override
	protected void configure(HttpSecurity http) throws Exception {
		// @formatter:off
		http
			// other config goes here...
			.sessionManagement()
				.maximumSessions(2)
				.sessionRegistry(sessionRegistry());
		// @formatter:on
	}

	@Bean
	public SpringSessionBackedSessionRegistry<S> sessionRegistry() {
		return new SpringSessionBackedSessionRegistry<>(this.sessionRepository);
	}
}

This assumes that you have also configured Spring Session to provide a FindByIndexNameSessionRepository that returns Session instances.

When using XML configuration, it would look something like the following listing:

<security:http>
	<!-- other config goes here... -->
	<security:session-management>
		<security:concurrency-control max-sessions="2" session-registry-ref="sessionRegistry"/>
	</security:session-management>
</security:http>

<bean id="sessionRegistry"
	  class="org.springframework.session.security.SpringSessionBackedSessionRegistry">
	<constructor-arg ref="sessionRepository"/>
</bean>

This assumes that your Spring Session SessionRegistry bean is called sessionRegistry, which is the name used by all SpringHttpSessionConfiguration subclasses.

Spring Session’s implementation of Spring Security’s SessionRegistry interface does not support the getAllPrincipals method, as this information cannot be retrieved by using Spring Session. This method is never called by Spring Security, so this affects only applications that access the SessionRegistry themselves.

A Session is a simplified Map of name value pairs.

Typical usage might look like the following listing:

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

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

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

		this.repository.save(toSave); 

		S session = this.repository.findById(toSave.getId()); 

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

	// ... setter methods ...
}

The Session API also provides attributes related to the Session instance’s expiration.

Typical usage might look like the following listing:

public class ExpiringRepositoryDemo<S extends Session> {
	private SessionRepository<S> repository; 

	public void demo() {
		S toSave = this.repository.createSession(); 
		// ...
		toSave.setMaxInactiveInterval(Duration.ofSeconds(30)); 

		this.repository.save(toSave); 

		S session = this.repository.findById(toSave.getId()); 
		// ...
	}

	// ... setter methods ...
}

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

If possible, you 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.

Spring Session’s most basic API for using a Session is the SessionRepository. This API is intentionally very simple, so that you can easily provide additional implementations with basic functionality.

Some SessionRepository implementations may also choose to implement FindByIndexNameSessionRepository. For example, Spring’s Redis, JDBC, and Hazelcast support libraries all implement FindByIndexNameSessionRepository.

The FindByIndexNameSessionRepository provides a method to look up all the sessions with a given index name and index value. As a common use case that is supported by all provided FindByIndexNameSessionRepository implementations, you can use a convenient method to look up all the sessions for a particular user. This is done by ensuring that the session attribute with the name of FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME is populated with the username. It is your responsibility to ensure that the attribute is populated, since Spring Session is not aware of the authentication mechanism being used. An example of how to use this can be seen in the following listing:

String username = "username";
this.session.setAttribute(
		FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME, username);

	Note
	Some implementations of FindByIndexNameSessionRepository provide hooks to automatically index other session attributes. For example, many implementations automatically ensure that the current Spring Security user name is indexed with the index name of FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME.

Once the session is indexed, you can find by using code similar to the following:

String username = "username";
Map<String, Session> sessionIdToSession = this.sessionRepository
		.findByPrincipalName(username);

A ReactiveSessionRepository is in charge of creating, retrieving, and persisting Session instances in a non-blocking and reactive manner.

If possible, you should not interact directly with a ReactiveSessionRepository or a Session. Instead, you should prefer interacting with ReactiveSessionRepository and Session indirectly through the WebSession integration.

You can add the @EnableSpringHttpSession annotation to a @Configuration class to expose the SessionRepositoryFilter as a bean named springSessionRepositoryFilter. In order to use the annotation, you must provide a single SessionRepository bean. The following example shows how to do so:

@EnableSpringHttpSession
@Configuration
public class SpringHttpSessionConfig {
	@Bean
	public MapSessionRepository sessionRepository() {
		return new MapSessionRepository(new ConcurrentHashMap<>());
	}
}

Note that no infrastructure for session expirations is configured for you. This is because things such as session expiration are highly implementation-dependent. This means that, if you need to clean up expired sessions, you are responsible for cleaning up the expired sessions.

You can add the @EnableSpringWebSession annotation to a @Configuration class to expose the WebSessionManager as a bean named webSessionManager. To use the annotation, you must provide a single ReactiveSessionRepository bean. The following example shows how to do so:

@EnableSpringWebSession
public class SpringWebSessionConfig {
	@Bean
	public ReactiveSessionRepository reactiveSessionRepository() {
		return new ReactiveMapSessionRepository(new ConcurrentHashMap<>());
	}
}

Note that no infrastructure for session expirations is configured for you. This is because things such as session expiration are highly implementation-dependent. This means that, if you require cleaning up expired sessions, you are responsible for cleaning up the expired sessions.

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

RedisTemplate<Object, Object> redisTemplate = new RedisTemplate<>();

// ... configure redisTemplate ...

SessionRepository<? extends Session> repository =
		new RedisOperationsSessionRepository(redisTemplate);

9.7.4 Storage Details

The following sections outline how Redis is updated for each operation. The following example shows an example of creating a new session:

HMSET spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe creationTime 1404360000000 \
	maxInactiveInterval 1800 \
	lastAccessedTime 1404360000000 \
	sessionAttr:attrName someAttrValue \
	sessionAttr2:attrName someAttrValue2
EXPIRE spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe 2100
APPEND spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe ""
EXPIRE spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe 1800
SADD spring:session:expirations:1439245080000 expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe
EXPIRE spring:session:expirations1439245080000 2100

The subsequent sections describe the details.

Saving a Session

Each session is stored in Redis as a Hash. Each session is set and updated by using the HMSET command. The following example shows how each session is stored:

HMSET spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe creationTime 1404360000000 \
	maxInactiveInterval 1800 \
	lastAccessedTime 1404360000000 \
	sessionAttr:attrName someAttrValue \
	sessionAttr2:attrName someAttrValue2

In the preceding example, the following statements are true about the session:

• The session ID is 33fdd1b6-b496-4b33-9f7d-df96679d32fe.
• The session was created at 1404360000000 (in milliseconds since midnight of 1/1/1970 GMT).
• The session expires in 1800 seconds (30 minutes).
• The session was last accessed at 1404360000000 (in milliseconds since midnight of 1/1/1970 GMT).
• The session has two attributes. The first is attrName, with a value of someAttrValue. The second session attribute is named attrName2, with a value of someAttrValue2.

Optimized Writes

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

HMSET spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe sessionAttr:attrName2 newValue

Session Expiration

An expiration is associated with each session by using the EXPIRE command, based upon the Session.getMaxInactiveInterval(). The following example shows a typical EXPIRE command:

EXPIRE spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe 2100

Note that the expiration that is set to five minutes after the session actually expires. This is necessary so that the value of the session can be accessed when the session expires. An expiration is set on the session itself five minutes after it actually expires to ensure that it is cleaned up, but only after we perform any necessary processing.

	Note
	The SessionRepository.findById(String) method ensures that no expired sessions are returned. This means that you need not check the expiration before using a session.

Spring Session relies on the delete and expired keyspace notifications from Redis to fire a SessionDeletedEvent and a SessionExpiredEvent, respectively. SessionDeletedEvent or SessionExpiredEvent ensure that resources associated with the Session are cleaned up. For example, when you use Spring Session’s WebSocket support, the Redis expired or delete event triggers any WebSocket connections associated with the session to be closed.

Expiration is not tracked directly on the session key itself, since this would mean the session data would no longer be available. Instead, a special session expires key is used. In the preceding example, the expires key is as follows:

APPEND spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe ""
EXPIRE spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe 1800

When a session expires key is deleted or expires, the keyspace notification triggers a lookup of the actual session, and a SessionDestroyedEvent is fired.

One problem with relying on Redis expiration exclusively is that, if the key has not been accessed, Redis makes no guarantee of when the expired event is fired. 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 the 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 removes the key and fires the expired event when we try to access the key.

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

SADD spring:session:expirations:1439245080000 expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe
EXPIRE spring:session:expirations1439245080000 2100

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

	Note
	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.

redis-cli config set notify-keyspace-events Egx

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

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

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

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"

ReactiveRedisOperationsSessionRepository is a ReactiveSessionRepository that is implemented by using Spring Data’s ReactiveRedisOperations. In a web environment, this is typically used in combination with WebSessionStore.

// ... create and configure connectionFactory and serializationContext ...

ReactiveRedisTemplate<String, Object> redisTemplate = new ReactiveRedisTemplate<>(
		connectionFactory, serializationContext);

ReactiveSessionRepository<? extends Session> repository =
		new ReactiveRedisOperationsSessionRepository(redisTemplate);

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

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"

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

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

	./gradlew :samples:hazelcast:tomcatRun

	./gradlew :samples:hazelcast-spring:tomcatRun

The ReactiveMapSessionRepository allows for persisting Session in a Map, with the key being the Session ID and the value being the Session. You can use the implementation with a ConcurrentHashMap as a testing or convenience mechanism. Alternatively, you can use it with distributed Map implementations, with the requirement that the supplied Map must be non-blocking.

JdbcOperationsSessionRepository is a SessionRepository implementation that uses Spring’s JdbcOperations to store sessions in a relational database. In a web environment, this is typically used in combination with SessionRepositoryFilter. Note that this implementation does not support publishing of session events.

JdbcTemplate jdbcTemplate = new JdbcTemplate();

// ... configure JdbcTemplate ...

PlatformTransactionManager transactionManager = new DataSourceTransactionManager();

// ... configure transactionManager ...

SessionRepository<? extends Session> repository =
		new JdbcOperationsSessionRepository(jdbcTemplate, transactionManager);

CREATE TABLE SPRING_SESSION (
	PRIMARY_ID CHAR(36) NOT NULL,
	SESSION_ID CHAR(36) NOT NULL,
	CREATION_TIME BIGINT NOT NULL,
	LAST_ACCESS_TIME BIGINT NOT NULL,
	MAX_INACTIVE_INTERVAL INT NOT NULL,
	EXPIRY_TIME BIGINT NOT NULL,
	PRINCIPAL_NAME VARCHAR(100),
	CONSTRAINT SPRING_SESSION_PK PRIMARY KEY (PRIMARY_ID)
);

CREATE UNIQUE INDEX SPRING_SESSION_IX1 ON SPRING_SESSION (SESSION_ID);
CREATE INDEX SPRING_SESSION_IX2 ON SPRING_SESSION (EXPIRY_TIME);
CREATE INDEX SPRING_SESSION_IX3 ON SPRING_SESSION (PRINCIPAL_NAME);

CREATE TABLE SPRING_SESSION_ATTRIBUTES (
	SESSION_PRIMARY_ID CHAR(36) NOT NULL,
	ATTRIBUTE_NAME VARCHAR(200) NOT NULL,
	ATTRIBUTE_BYTES BYTEA NOT NULL,
	CONSTRAINT SPRING_SESSION_ATTRIBUTES_PK PRIMARY KEY (SESSION_PRIMARY_ID, ATTRIBUTE_NAME),
	CONSTRAINT SPRING_SESSION_ATTRIBUTES_FK FOREIGN KEY (SESSION_PRIMARY_ID) REFERENCES SPRING_SESSION(PRIMARY_ID) ON DELETE CASCADE
);

CREATE TABLE SPRING_SESSION (
	PRIMARY_ID CHAR(36) NOT NULL,
	SESSION_ID CHAR(36) NOT NULL,
	CREATION_TIME BIGINT NOT NULL,
	LAST_ACCESS_TIME BIGINT NOT NULL,
	MAX_INACTIVE_INTERVAL INT NOT NULL,
	EXPIRY_TIME BIGINT NOT NULL,
	PRINCIPAL_NAME VARCHAR(100),
	CONSTRAINT SPRING_SESSION_PK PRIMARY KEY (PRIMARY_ID)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;

CREATE UNIQUE INDEX SPRING_SESSION_IX1 ON SPRING_SESSION (SESSION_ID);
CREATE INDEX SPRING_SESSION_IX2 ON SPRING_SESSION (EXPIRY_TIME);
CREATE INDEX SPRING_SESSION_IX3 ON SPRING_SESSION (PRINCIPAL_NAME);

CREATE TABLE SPRING_SESSION_ATTRIBUTES (
	SESSION_PRIMARY_ID CHAR(36) NOT NULL,
	ATTRIBUTE_NAME VARCHAR(200) NOT NULL,
	ATTRIBUTE_BYTES BLOB NOT NULL,
	CONSTRAINT SPRING_SESSION_ATTRIBUTES_PK PRIMARY KEY (SESSION_PRIMARY_ID, ATTRIBUTE_NAME),
	CONSTRAINT SPRING_SESSION_ATTRIBUTES_FK FOREIGN KEY (SESSION_PRIMARY_ID) REFERENCES SPRING_SESSION(PRIMARY_ID) ON DELETE CASCADE
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;

HazelcastSessionRepository is a SessionRepository implementation that stores sessions in Hazelcast’s distributed IMap. In a web environment, this is typically used in combination with SessionRepositoryFilter.

Config config = new Config();

// ... configure Hazelcast ...

HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance(config);

HazelcastSessionRepository repository =
		new HazelcastSessionRepository(hazelcastInstance);

Spring Session 2.0 requires Java 8 and Spring Framework 5.0 as a baseline, since its entire codebase is now based on Java 8 source code. See Upgrading to Spring Framework 5.x for more on upgrading Spring Framework.

As a part of the project’s splitting of the modules, the existing spring-session has been replaced with the spring-session-core module. The spring-session-core module holds only the common set of APIs and components, while other modules contain the implementation of the appropriate SessionRepository and functionality related to that data store. This applies to several existing modules that were previously a simple dependency aggregator helper module. With new module arrangement, the following modules actually carry the implementation:

Also, the following modules were removed from the main project repository:

Note that these two have moved to separate repositories and continue to be available under new artifact names:

The following changes were made to packages, classes, and methods:

As a part of the changes to HttpSessionStrategy and its alignment to the counterpart from the reactive world, the support for managing multiple users' sessions in a single browser instance has been removed. The introduction of a new API to replace this functionality is under consideration for future releases.

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

You can find the source code on GitHub at https://github.com/spring-projects/spring-session/

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

We appreciate pull requests.

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