This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Session 3.1.7! |
API Documentation
You can browse the complete Javadoc online. The key APIs are described in the following sections:
Using Session
A Session
is a simplified Map
of name value pairs.
Typical usage might look like the following listing:
class RepositoryDemo<S extends Session> {
private SessionRepository<S> repository; (1)
void demo() {
S toSave = this.repository.createSession(); (2)
(3)
User rwinch = new User("rwinch");
toSave.setAttribute(ATTR_USER, rwinch);
this.repository.save(toSave); (4)
S session = this.repository.findById(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 by 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 by using the same SessionRepository . This allows for the SessionRepository to make implementation specific optimizations (that is, writing only 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. |
The Session
API also provides attributes related to the Session
instance’s expiration.
Typical usage might look like the following listing:
class ExpiringRepositoryDemo<S extends Session> {
private SessionRepository<S> repository; (1)
void demo() {
S toSave = this.repository.createSession(); (2)
// ...
toSave.setMaxInactiveInterval(Duration.ofSeconds(30)); (3)
this.repository.save(toSave); (4)
S session = this.repository.findById(toSave.getId()); (5)
// ...
}
// ... 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 by using our SessionRepository and assign it to a variable of type S . |
3 | We interact with the Session .
In our example, we demonstrate updating the amount of time the Session can be inactive before it expires. |
4 | We now save the Session .
This is why we needed the generic type, S .
The SessionRepository allows saving only Session instances that were created or retrieved using the same SessionRepository .
This allows for the SessionRepository to make implementation specific optimizations (that is, writing only attributes that have changed).
The last accessed time is automatically updated when the Session is saved. |
5 | We retrieve the Session from the SessionRepository .
If the Session were expired, the result would be null. |
Using SessionRepository
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.
Using FindByIndexNameSessionRepository
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);
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);
Using ReactiveSessionRepository
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.
Using @EnableSpringHttpSession
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.
Using @EnableSpringWebSession
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:
@Configuration(proxyBeanMethods = false)
@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.
Using RedisSessionRepository
RedisSessionRepository
is a SessionRepository
that is implemented by using Spring Data’s RedisOperations
.
In a web environment, this is typically used in combination with SessionRepositoryFilter
.
Note that this implementation does not support publishing of session events.
Instantiating a RedisSessionRepository
You can see a typical example of how to create a new instance in the following listing:
RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
// ... configure redisTemplate ...
SessionRepository<? extends Session> repository = new RedisSessionRepository(redisTemplate);
For additional information on how to create a RedisConnectionFactory
, see the Spring Data Redis Reference.
Using @EnableRedisHttpSession
In a web environment, the simplest way to create a new RedisSessionRepository
is to use @EnableRedisHttpSession
.
You can find complete example usage in the Samples and Guides (Start Here).
You can use the following attributes to customize the configuration:
enableIndexingAndEvents
* enableIndexingAndEvents: Whether to use a RedisIndexedSessionRepository
instead of a RedisSessionRepository
. The default is false
.
* maxInactiveIntervalInSeconds: The amount of time before the session expires, in seconds.
* redisNamespace: Allows configuring an application specific namespace for the sessions. Redis keys and channel IDs start with the prefix of <redisNamespace>:
.
* flushMode: Allows specifying when data is written to Redis. The default is only when save
is invoked on SessionRepository
.
A value of FlushMode.IMMEDIATE
writes to Redis as soon as possible.
Viewing the Session in Redis
After installing redis-cli, you can inspect the values in Redis using the redis-cli. For example, you can enter the following command into a terminal window:
$ redis-cli
redis 127.0.0.1:6379> keys *
1) "spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021" (1)
1 | The suffix of this key is the session identifier of the Spring Session. |
You can also view the attributes of each session by using the hkeys
command.
The following example shows how to do so:
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"
Using RedisIndexedSessionRepository
RedisIndexedSessionRepository
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
.
Instantiating a RedisIndexedSessionRepository
You can see a typical example of how to create a new instance in the following listing:
RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
// ... configure redisTemplate ...
SessionRepository<? extends Session> repository = new RedisIndexedSessionRepository(redisTemplate);
For additional information on how to create a RedisConnectionFactory
, see the Spring Data Redis Reference.
Using @EnableRedisHttpSession(enableIndexingAndEvents = true)
In a web environment, the simplest way to create a new RedisIndexedSessionRepository
is to use @EnableRedisHttpSession(enableIndexingAndEvents = true)
.
You can find complete example usage in the Samples and Guides (Start Here).
You can use the following attributes to customize the configuration:
-
enableIndexingAndEvents: Whether to use a
RedisIndexedSessionRepository
instead of aRedisSessionRepository
. The default isfalse
. -
maxInactiveIntervalInSeconds: The amount of time before the session expires, in seconds.
-
redisNamespace: Allows configuring an application specific namespace for the sessions. Redis keys and channel IDs start with the prefix of
<redisNamespace>:
. -
flushMode: Allows specifying when data is written to Redis. The default is only when
save
is invoked onSessionRepository
. A value ofFlushMode.IMMEDIATE
writes to Redis as soon as possible.
Redis TaskExecutor
RedisIndexedSessionRepository
is subscribed to receive events from Redis by using a RedisMessageListenerContainer
.
You can customize the way those events are dispatched by creating a bean named springSessionRedisTaskExecutor
, a bean springSessionRedisSubscriptionExecutor
, or both.
You can find more details on configuring Redis task executors here.
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 \ sessionAttr:attrName2 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 \ sessionAttr:attrName2 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 ofsomeAttrValue
. The second session attribute is namedattrName2
, with a value ofsomeAttrValue2
.
Optimized Writes
The Session
instances managed by RedisIndexedSessionRepository
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 attrName2
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.
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.
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. |
SessionDeletedEvent
and SessionExpiredEvent
SessionDeletedEvent
and SessionExpiredEvent
are both types of SessionDestroyedEvent
.
RedisIndexedSessionRepository
supports firing a SessionDeletedEvent
when a Session
is deleted or a SessionExpiredEvent
when a Session
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 SessionDeletedEvent
or SessionExpiredEvent
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.
The following example shows how to do so:
redis-cli config set notify-keyspace-events Egx
If you use @EnableRedisHttpSession(enableIndexingAndEvents = true)
, managing 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, with Java configuration, you can use the following:
@Bean
ConfigureRedisAction configureRedisAction() {
return ConfigureRedisAction.NO_OP;
}
In XML configuration, you can use the following:
<util:constant
static-field="org.springframework.session.data.redis.config.ConfigureRedisAction.NO_OP"/>
Using SessionCreatedEvent
When a session is created, an event is sent to Redis with a channel ID of spring:session:channel:created:33fdd1b6-b496-4b33-9f7d-df96679d32fe
,
where 33fdd1b6-b496-4b33-9f7d-df96679d32fe
is the session ID. The body of the event is the session that was created.
If registered as a MessageListener
(the default), RedisIndexedSessionRepository
then translates the Redis message into a SessionCreatedEvent
.
Viewing the Session in Redis
After installing redis-cli, you can inspect the values in Redis using the redis-cli. For example, you can 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. The following example shows how to do so:
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"
Using ReactiveRedisSessionRepository
ReactiveRedisSessionRepository
is a ReactiveSessionRepository
that is implemented by using Spring Data’s ReactiveRedisOperations
.
In a web environment, this is typically used in combination with WebSessionStore
.
Instantiating a ReactiveRedisSessionRepository
The following example shows how to create a new instance:
// ... create and configure connectionFactory and serializationContext ...
ReactiveRedisTemplate<String, Object> redisTemplate = new ReactiveRedisTemplate<>(connectionFactory,
serializationContext);
ReactiveSessionRepository<? extends Session> repository = new ReactiveRedisSessionRepository(redisTemplate);
For additional information on how to create a ReactiveRedisConnectionFactory
, see the Spring Data Redis Reference.
Using @EnableRedisWebSession
In a web environment, the simplest way to create a new ReactiveRedisSessionRepository
is to use @EnableRedisWebSession
.
You can use the following attributes to customize the configuration:
-
maxInactiveIntervalInSeconds: The amount of time before the session expires, in seconds
-
redisNamespace: Allows configuring an application specific namespace for the sessions. Redis keys and channel IDs start with q prefix of
<redisNamespace>:
. -
flushMode: Allows specifying when data is written to Redis. The default is only when
save
is invoked onReactiveSessionRepository
. A value ofFlushMode.IMMEDIATE
writes to Redis as soon as possible.
Viewing the Session in Redis
After installing redis-cli, you can inspect the values in Redis using the redis-cli. For example, you can enter the following command into a terminal window:
$ redis-cli
redis 127.0.0.1:6379> keys *
1) "spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021" (1)
1 | The suffix of this key is the session identifier of the Spring Session. |
You can also view the attributes of each session by using the hkeys
command.
The following example shows how to do so:
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"
Using MapSessionRepository
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.
Instantiating MapSessionRepository
The following example shows how to create a new instance:
SessionRepository<? extends Session> repository = new MapSessionRepository(new ConcurrentHashMap<>());
Using Spring Session and Hazlecast
The Hazelcast Sample is a complete application that demonstrates how to use Spring Session with Hazelcast.
To run it, use the following command:
./gradlew :samples:hazelcast:tomcatRun
The Hazelcast Spring Sample is a complete application that demonstrates how to use Spring Session with Hazelcast and Spring Security.
It includes example Hazelcast MapListener
implementations that support firing SessionCreatedEvent
, SessionDeletedEvent
, and SessionExpiredEvent
.
To run it, use the following command:
./gradlew :samples:hazelcast-spring:tomcatRun
Using ReactiveMapSessionRepository
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.
Using JdbcIndexedSessionRepository
JdbcIndexedSessionRepository
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.
Instantiating a JdbcIndexedSessionRepository
The following example shows how to create a new instance:
JdbcTemplate jdbcTemplate = new JdbcTemplate();
// ... configure jdbcTemplate ...
TransactionTemplate transactionTemplate = new TransactionTemplate();
// ... configure transactionTemplate ...
SessionRepository<? extends Session> repository = new JdbcIndexedSessionRepository(jdbcTemplate,
transactionTemplate);
For additional information on how to create and configure JdbcTemplate
and PlatformTransactionManager
, see the Spring Framework Reference Documentation.
Using @EnableJdbcHttpSession
In a web environment, the simplest way to create a new JdbcIndexedSessionRepository
is to use @EnableJdbcHttpSession
.
You can find complete example usage in the Samples and Guides (Start Here)
You can use the following attributes to customize the configuration:
-
tableName: The name of database table used by Spring Session to store sessions
-
maxInactiveIntervalInSeconds: The amount of time before the session will expire in seconds
Customizing LobHandler
You can customize BLOB handling by creating a bean named springSessionLobHandler
that implements LobHandler
.
Customizing ConversionService
You can customize the default serialization and deserialization of the session by providing a ConversionService
instance.
When working in a typical Spring environment, the default ConversionService
bean (named conversionService
) is automatically picked up and used for serialization and deserialization.
However, you can override the default ConversionService
by providing a bean named springSessionConversionService
.
Storage Details
By default, this implementation uses SPRING_SESSION
and SPRING_SESSION_ATTRIBUTES
tables to store sessions.
Note that you can customize the table name, as already described. In that case, the table used to store attributes is named by using the provided table name suffixed with _ATTRIBUTES
.
If further customizations are needed, you can customize the SQL queries used by the repository by using set*Query
setter methods. In this case, you need to manually configure the sessionRepository
bean.
Due to the differences between the various database vendors, especially when it comes to storing binary data, make sure to use SQL scripts specific to your database.
Scripts for most major database vendors are packaged as org/springframework/session/jdbc/schema-*.sql
, where *
is the target database type.
For example, with PostgreSQL, you can use the following schema script:
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
);
With MySQL database, you can use the following script:
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;
Transaction Management
All JDBC operations in JdbcIndexedSessionRepository
are performed in a transactional manner.
Transactions are performed with propagation set to REQUIRES_NEW
in order to avoid unexpected behavior due to interference with existing transactions (for example, running a save
operation in a thread that already participates in a read-only transaction).
Using HazelcastIndexedSessionRepository
HazelcastIndexedSessionRepository
is a SessionRepository
implementation that stores sessions in Hazelcast’s distributed IMap
.
In a web environment, this is typically used in combination with SessionRepositoryFilter
.
Instantiating a HazelcastIndexedSessionRepository
The following example shows how to create a new instance:
Config config = new Config();
// ... configure Hazelcast ...
HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance(config);
HazelcastIndexedSessionRepository repository = new HazelcastIndexedSessionRepository(hazelcastInstance);
For additional information on how to create and configure Hazelcast instance, see the Hazelcast documentation.
Using @EnableHazelcastHttpSession
To use Hazelcast as your backing source for the SessionRepository
, you can add the @EnableHazelcastHttpSession
annotation to a @Configuration
class.
Doing so extends the functionality provided by the @EnableSpringHttpSession
annotation but makes the SessionRepository
for you in Hazelcast.
You must provide a single HazelcastInstance
bean for the configuration to work.
You can find a complete configuration example in the Samples and Guides (Start Here).
Basic Customization
You can use the following attributes on @EnableHazelcastHttpSession
to customize the configuration:
-
maxInactiveIntervalInSeconds: The amount of time before the session expires, in seconds. The default is 1800 seconds (30 minutes)
-
sessionMapName: The name of the distributed
Map
that is used in Hazelcast to store the session data.
Session Events
Using a MapListener
to respond to entries being added, evicted, and removed from the distributed Map
causes these events to trigger publishing of SessionCreatedEvent
, SessionExpiredEvent
, and SessionDeletedEvent
events (respectively) through the ApplicationEventPublisher
.
Storage Details
Sessions are stored in a distributed IMap
in Hazelcast.
The IMap
interface methods are used to get()
and put()
Sessions.
Additionally, the values()
method supports a FindByIndexNameSessionRepository#findByIndexNameAndIndexValue
operation, together with appropriate ValueExtractor
(which needs to be registered with Hazelcast). See the Hazelcast Spring Sample for more details on this configuration.
The expiration of a session in the IMap
is handled by Hazelcast’s support for setting the time to live on an entry when it is put()
into the IMap
. Entries (sessions) that have been idle longer than the time to live are automatically removed from the IMap
.
You should not need to configure any settings such as max-idle-seconds
or time-to-live-seconds
for the IMap
within the Hazelcast configuration.
Note that if you use Hazelcast’s MapStore
to persist your sessions IMap
, the following limitations apply when reloading the sessions from MapStore
:
-
Reloading triggers
EntryAddedListener
results inSessionCreatedEvent
being re-published -
Reloading uses default TTL for a given
IMap
results in sessions losing their original TTL
Using CookieSerializer
A CookieSerializer
is responsible for defining how the session cookie is written.
Spring Session comes with a default implementation using DefaultCookieSerializer
.
Exposing CookieSerializer
as a bean
Exposing the CookieSerializer
as a Spring bean augments the existing configuration when you use configurations like @EnableRedisHttpSession
.
The following example shows how to do so:
@Bean
public CookieSerializer cookieSerializer() {
DefaultCookieSerializer serializer = new DefaultCookieSerializer();
serializer.setCookieName("JSESSIONID"); (1)
serializer.setCookiePath("/"); (2)
serializer.setDomainNamePattern("^.+?\\.(\\w+\\.[a-z]+)$"); (3)
return serializer;
}
1 | We customize the name of the cookie to be JSESSIONID . |
2 | We customize the path of the cookie to be / (rather than the default of the context root). |
3 | We customize the domain name pattern (a regular expression) to be ^.?\\.(\\w\\.[a-z]+)$ .
This allows sharing a session across domains and applications.
If the regular expression does not match, no domain is set and the existing domain is used.
If the regular expression matches, the first grouping is used as the domain.
This means that a request to child.example.com sets the domain to example.com .
However, a request to localhost:8080/ or 192.168.1.100:8080/ leaves the cookie unset and, thus, still works in development without any changes being necessary for production. |
You should only match on valid domain characters, since the domain name is reflected in the response. Doing so prevents a malicious user from performing such attacks as HTTP Response Splitting. |
Customizing CookieSerializer
You can customize how the session cookie is written by using any of the following configuration options on the DefaultCookieSerializer
.
-
cookieName
: The name of the cookie to use. Default:SESSION
. -
useSecureCookie
: Specifies whether a secure cookie should be used. Default: Use the value ofHttpServletRequest.isSecure()
at the time of creation. -
cookiePath
: The path of the cookie. Default: The context root. -
cookieMaxAge
: Specifies the max age of the cookie to be set at the time the session is created. Default:-1
, which indicates the cookie should be removed when the browser is closed. -
jvmRoute
: Specifies a suffix to be appended to the session ID and included in the cookie. Used to identify which JVM to route to for session affinity. With some implementations (that is, Redis) this option provides no performance benefit. However, it can help with tracing logs of a particular user. -
domainName
: Allows specifying a specific domain name to be used for the cookie. This option is simple to understand but often requires a different configuration between development and production environments. SeedomainNamePattern
as an alternative. -
domainNamePattern
: A case-insensitive pattern used to extract the domain name from theHttpServletRequest#getServerName()
. The pattern should provide a single grouping that is used to extract the value of the cookie domain. If the regular expression does not match, no domain is set and the existing domain is used. If the regular expression matches, the first grouping is used as the domain. -
sameSite
: The value for theSameSite
cookie directive. To disable the serialization of theSameSite
cookie directive, you may set this value tonull
. Default:Lax
You should only match on valid domain characters, since the domain name is reflected in the response. Doing so prevents a malicious user from performing such attacks as HTTP Response Splitting. |
Customizing SessionRepository
Implementing a custom SessionRepository
API should be a fairly straightforward task.
Coupling the custom implementation with @EnableSpringHttpSession
support lets you reuse existing Spring Session configuration facilities and infrastructure.
There are, however, a couple of aspects that deserve closer consideration.
During the lifecycle of an HTTP request, the HttpSession
is typically persisted to SessionRepository
twice.
The first persist operation is to ensure that the session is available to the client as soon as the client has access to the session ID, and it is also necessary to write after the session is committed because further modifications to the session might be made.
Having this in mind, we generally recommend that a SessionRepository
implementation keep track of changes to ensure that only deltas are saved.
This is particularly important in highly concurrent environments, where multiple requests operate on the same HttpSession
and, therefore, cause race conditions, with requests overriding each other’s changes to session attributes.
All of the SessionRepository
implementations provided by Spring Session use the described approach to persist session changes and can be used for guidance when you implement custom SessionRepository
.
Note that the same recommendations apply for implementing a custom ReactiveSessionRepository
as well.
In this case, you should use the @EnableSpringWebSession
.