Use cases for Store interface

[sandalovsergey]

Hi everyone! @mrniko

In continuation of #878 issue I wanted to ask: is the Store interface still relevant?

Little background: start moving from single to multiple instances we found this article. When Redis was introduced in configs we found that there are a lot of entities in Redis after a couple of days. Diving into the code I found that there is place where library add entity to Redis and THERE IS NO place where this entity would be deleted. So, here is the first bunch of questions(Q1): why was this strategy chosen? If you have a lot of connect->action->disconect flows your Redis cluster will be overflowing with disconnected client sessions! And it is also interesting that the other methods(like get(), has(), del()) are not called anywhere else in the library besides overrides here

Moving forward: after this I started to ask myself (second bunch of questions(Q2))-- what are the possible use cases for storing client sessions? And does it makes sence at all to operate with library object(sid from socket-io) whose life cycle I do not own? Inspecting code add/change time(late 2013) I started to think that it maybe obsolete approach.

To sum up:
Q1

• why library only set client session to Redis and never get/has/del it?
• is it my responsibility to do that or I made a mistake and library DOES it?
• are there plans to separate concerns in Store Factory? Maybe createStore() will be optional only if useSessionStore=true for example?

Q2

• can you provide use cases for correct client session management?
• why I should prefer to operate with client session rather that using broadcast operations and etc?
• for now I see the following way: extend RedisStoreFactory and simply /dev/null Store in createStore(). But is this really the right thing to do?

UPD: I was able to remember a sample case from Spring Session: here. F.e. we can index our sessions by its ownerId. And therefore can query all session by ownerId. But is it really the case in the context of your library?