-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
Provide option to always load sessions from database #17
Comments
@zhanghepeng , yes the library works with redis 4.0 |
…abase if used, implement the feature request: #17
Your feature request is implemented, It's done on both iris and here, |
Seems like the format in which data stored stored in backend has changed drastically so existing users has to flush all backend sessions before going live with this version. Found a major flaw in new redis backend is architecture, I will create new issue explaining it. |
Yes, you asked months ago, assume you were prepared for it... I am not a redis fan but ofc, if you find any bug I will do my bests to fix it, thank you a lot @vividvilla |
Hi
Thanks for your work on this library, @kataras .
This is regarding the in-memory session state stored by this library(after the first Start()).
Many multi-process/multi-node app setups share a common backend database to persist sessions. Only loading the sessions for the first time into memory leads to inconsistent state across multiple instances of the application. This request has been raised few times already by users of this library(or its fork in Iris framework): #12 , kataras/iris#885 .
The proposal is to add a Config flag(defaults to false) to enable always looking up the session in the backend database. This way, users that have multiple instances sharing the same database can still have consistent state across instances without disturbing the current in-memory behaviour.
This being a standalone sessions library(not tied to any framework) should definitely have a way to use the library in a multi-machine with common backend setup as most users would expect the library to have consistent state in such situations. Here's an easy fix for this issue. Your thoughts?
The text was updated successfully, but these errors were encountered: