You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/docs/asciidoc/index.adoc
+16-3Lines changed: 16 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -294,8 +294,19 @@ For example:
294
294
295
295
EXPIRE spring:session:sessions:<session-id> 1800
296
296
297
-
Each session expiration is also tracked to the nearest minute.
298
-
This allows a background task to cleanup expired sessions in a deterministic fashion.
297
+
Spring Session relies on the expired and delete http://redis.io/topics/notifications[keyspace notifications] from Redis to fire a <<SessionDestroyedEvent>>.
298
+
It is the `SessionDestroyedEvent` that ensures resources associated with the Session are cleaned up.
299
+
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.
300
+
301
+
One problem with this approach is that Redis makes no guarantee of when the expired event will be fired if they key has not been accessed.
302
+
Specifically the background task that Redis uses to clean up expired keys is a low priority task and may not trigger the key expiration.
303
+
For additional details see http://redis.io/topics/notifications[Timing of expired events] section in the Redis documentation.
304
+
305
+
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.
306
+
This means that if the TTL is expired on the key, Redis will remove the key and fire the expired event when we try to access they key.
307
+
308
+
For this reason, each session expiration is also tracked to the nearest minute.
309
+
This allows a background task to access the potentially expired sessions to ensure that Redis expired events are fired in a more deterministic fashion.
The background task will then use these mappings to explicitly request each key.
305
316
By accessing they key, rather than deleting it, we ensure that Redis deletes the key for us only if the TTL is expired.
306
317
307
-
The Redis expiration is still placed on each key to ensure that if the server is down when the session expires, it is still cleaned up.
318
+
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.
319
+
Short of using distributed locks (which would kill our performance) there is no way to ensure the consistency of the expiration mapping.
320
+
By simply accessing the key, we ensure that the key is only removed if the TTL on that key is expired.
* Each session expiration is also tracked to the nearest minute. This allows a
99
-
* background task to cleanup expired sessions in a deterministic fashion. For
100
-
* example:
98
+
* <p>
99
+
* Spring Session relies on the expired and delete <a href="http://redis.io/topics/notifications">keyspace notifications</a> from Redis to fire a <<SessionDestroyedEvent>>.
100
+
* It is the `SessionDestroyedEvent` that ensures resources associated with the Session are cleaned up.
101
+
* For example, when using Spring Session's WebSocket support the Redis expired or delete event is what triggers any
102
+
* WebSocket connections associated with the session to be closed.
103
+
* </p>
104
+
*
105
+
* <p>
106
+
* One problem with this approach is that Redis makes no guarantee of when the expired event will be fired if they key has not been accessed.
107
+
* Specifically the background task that Redis uses to clean up expired keys is a low priority task and may not trigger the key expiration.
108
+
* For additional details see <a href="http://redis.io/topics/notifications">Timing of expired events</a> section in the Redis documentation.
109
+
* </p>
110
+
*
111
+
* <p>
112
+
* 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.
113
+
* This means that if the TTL is expired on the key, Redis will remove the key and fire the expired event when we try to access they key.
114
+
* </p>
115
+
*
116
+
* <p>
117
+
* For this reason, each session expiration is also tracked to the nearest minute.
118
+
* This allows a background task to access the potentially expired sessions to ensure that Redis expired events are fired in a more deterministic fashion.
* By accessing they key, rather than deleting it, we ensure that Redis deletes the key for us only if the TTL is expired.
110
130
* </p>
111
131
* <p>
112
-
* The Redis expiration is still placed on each key to ensure that if the server
113
-
* is down when the session expires, it is still cleaned up.
132
+
* <b>NOTE</b>: 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.
133
+
* Short of using distributed locks (which would kill our performance) there is no way to ensure the consistency of the expiration mapping.
134
+
* By simply accessing the key, we ensure that the key is only removed if the TTL on that key is expired.
0 commit comments