-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use cases for Store interface #982
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
createStore()
will be optional only ifuseSessionStore=true
for example?Q2
RedisStoreFactory
and simply/dev/null
Store
increateStore()
. 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?
The text was updated successfully, but these errors were encountered: