Feature to handle Deletion/Expiration in ReactiveRedisSessionRepository similar to RedisIndexedSessionRepository

[anrajamani13]

Context
Feature similar requested in [ReactiveRedisSessionRepository as similar to RedisIndexedSessionRepository (Expiration of keys to be handled in Spring framework instead of Redis expiry)

Motivation:
In Redis, there is no hard rule, that key will gets deleted once the TTL is expired, as expiration runs in a separate background thread, which is of least priority.

This scenario is handled in spring as part of RedisIndexedSessionRepository (3 keys gets created as part of session)
1)spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe
2)spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe
3)spring:session:expirations1439245080000
With the help of keys 2 and 3 and its TTL, Spring-session framework decides, spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe to. be accessed or deleted``` and deltion is taken care as part of scheduled cron job

Where as in case of ReactiveRedisSessionRepository, there is no such feature. Seems like expiration is completely handed over to redis.

Is there any reason/motivation behind, for not having this feature present in ReactiveRedisRepository as its good to have from session mgmt.

[anrajamani13]

Any update on this?

[HJK181]

A feedback after almost a year would be nice.

[marcusdacoregio]

Hi folks, I'm looking into prioritizing #914 for 3.3. Probably the first two implementations would be based on R2DBC #1748 and Redis