Package org.springframework.session.data.redis

Class ReactiveRedisIndexedSessionRepository

java.lang.Object
org.springframework.session.data.redis.ReactiveRedisIndexedSessionRepository
All Implemented Interfaces:
org.springframework.beans.factory.DisposableBean, org.springframework.beans.factory.InitializingBean, ReactiveFindByIndexNameSessionRepository<ReactiveRedisIndexedSessionRepository.RedisSession>, ReactiveSessionRepository<ReactiveRedisIndexedSessionRepository.RedisSession>
public class ReactiveRedisIndexedSessionRepository extends Object implements ReactiveSessionRepository<ReactiveRedisIndexedSessionRepository.RedisSession>, ReactiveFindByIndexNameSessionRepository<ReactiveRedisIndexedSessionRepository.RedisSession>, org.springframework.beans.factory.DisposableBean, org.springframework.beans.factory.InitializingBean
A ReactiveSessionRepository that is implemented using Spring Data's ReactiveRedisOperations.

Storage Details

The sections below outline how Redis is updated for each operation. An example of creating a new session can be found below. The subsequent sections describe the details. 
 HMSET spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381 creationTime 1702400400000 maxInactiveInterval 1800 lastAccessedTime 1702400400000 sessionAttr:attrName someAttrValue sessionAttr:attrName2 someAttrValue2
 EXPIRE spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381 2100
 APPEND spring:session:sessions:expires:648377f7-c76f-4f45-b847-c0268bb48381 ""
 EXPIRE spring:session:sessions:expires:648377f7-c76f-4f45-b847-c0268bb48381 1800
 ZADD spring:session:sessions:expirations "1.702402961162E12" "648377f7-c76f-4f45-b847-c0268bb48381"
 SADD spring:session:sessions:index:PRINCIPAL_NAME_INDEX_NAME:user "648377f7-c76f-4f45-b847-c0268bb48381"
 SADD spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381:idx "spring:session:sessions:index:PRINCIPAL_NAME_INDEX_NAME:user"

Saving a Session

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:648377f7-c76f-4f45-b847-c0268bb48381 creationTime 1702400400000 maxInactiveInterval 1800 lastAccessedTime 1702400400000 sessionAttr:attrName someAttrValue sessionAttr:attrName2 someAttrValue2

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

  • The session id is 648377f7-c76f-4f45-b847-c0268bb48381
  • The session was created at 1702400400000 in milliseconds since midnight of 1/1/1970 GMT.
  • The session expires in 1800 seconds (30 minutes).
  • The session was last accessed at 1702400400000 in milliseconds since midnight of 1/1/1970 GMT.
  • The session has two attributes. The first is "attrName" with the value of "someAttrValue". The second session attribute is named "attrName2" with the value of "someAttrValue2".

Optimized Writes

The ReactiveRedisIndexedSessionRepository.RedisSession 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 "attrName2" from earlier was updated. The following would be executed upon saving: 

 HMSET spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381 sessionAttr:attrName2 newValue

SessionCreatedEvent

When a session is created an event is sent to Redis with the channel of "spring:session:event:0:created:648377f7-c76f-4f45-b847-c0268bb48381" such that "648377f7-c76f-4f45-b847-c0268bb48381" is the session id. The body of the event will be the session that was created.

SessionDeletedEvent and SessionExpiredEvent

If you configured you Redis server to send keyspace events when keys are expired or deleted, either via ConfigureNotifyKeyspaceEventsReactiveAction or via external configuration, then deleted and expired sessions will be published as SessionDeletedEvent and SessionExpiredEvent respectively.

Expiration

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

 EXPIRE spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381 2100

You will note that the expiration that is set is 5 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 it is cleaned up, but only after we perform any necessary processing.

NOTE: The findById(String) method ensures that no expired sessions will be returned. This means there is no need to check the expiration before using a session.

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.

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 our example the expires key is: 

 APPEND spring:session:sessions:expires:648377f7-c76f-4f45-b847-c0268bb48381 ""
 EXPIRE spring:session:sessions:expires:648377f7-c76f-4f45-b847-c0268bb48381 1800

When a session 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 Redis makes no guarantee of when the expired event will be fired if the key has not been accessed. For additional details see How Redis expires keys section in the Redis Expire 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 the key.

For this reason, each session expiration is also tracked by storing the session id in a sorted set ranked by its expiration time. 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: 

 ZADD spring:session:sessions:expirations "1.702402961162E12" "648377f7-c76f-4f45-b847-c0268bb48381"

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.

Secondary Indexes

By default, Spring Session will also index the sessions by identifying if the session contains any attribute that can be mapped to a principal using an PrincipalNameIndexResolver. All resolved indexes for a session are stored in a Redis Set, for example: 
 SADD spring:session:sessions:index:PRINCIPAL_NAME_INDEX_NAME:user "648377f7-c76f-4f45-b847-c0268bb48381"
 SADD spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381:idx "spring:session:sessions:index:PRINCIPAL_NAME_INDEX_NAME:user"
Therefore, you can check all indexes for a given session by getting the members of the "spring:session:sessions:648377f7-c76f-4f45-b847-c0268bb48381:idx" Redis set.
Since:
3.3