Data stored in Spring (HTTP) Session is not removed from Redis during destroy

Question

i am doing a PoC with the newly released Spring Session component. This is backed-up by Redis repository, where both the Session and the objects/data stored in session are persisted to.

1. Session got created in the application
2. ran the "Keys *" command in Redis CLI and saw a new entry (like "spring:session:sessions:6b55103a-baf5-4a05-a127-3a9cfa15c164")
3. From the application, Added a custom bean to the session
4. ran the "Keys *" command in Redis CLI and saw one more new entry for this bean (like "\xac\xed\x00\x05t\x00\tcustomer1" , because the bean had a string with value 'customer1')
5. I had configured an auto expiry of 30 seconds and left the application unused for that time
6. The sessionDestroyEvent got triggered and was captured in the Listener implementing ApplicationListener
7. ran the "Keys *" command in Redis CLI and now the first created entry for the session was gone but, the custom bean object (customer1) was still left over in Redis

Question:

Is it the user responsibility to clean-up the Redis Store ? If i had many data elements stored in my session, should i have to manually clean them up from the redis store during session destroy (logout and timeout events).

Update:

While i posted this question and went back (probably after 3/4 mins) to Redis-CLI to list the Keys, now i do not find the Customer1 object. So does that mean the clean-up is performed by Redis on some regular interval, like the Garbage collection ?

Answer 1

The Session Expiration section Spring Session reference describes in detail how sessions are cleaned up.

From the documentation:

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

...

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