go-sessions icon indicating copy to clipboard operation
go-sessions copied to clipboard

Provide option to always load sessions from database

Open cheesedosa opened this issue 6 years ago • 4 comments

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?

cheesedosa avatar Jan 31 '18 21:01 cheesedosa

@zhanghepeng , yes the library works with redis 4.0

cheesedosa avatar Apr 08 '18 19:04 cheesedosa

Your feature request is implemented, It's done on both iris and here, go-sessions @cheesedosa, now databases (redis and badger) sync all actions, no memory storage if a database is used, only direct database calls, with commit: https://github.com/kataras/go-sessions/commit/70db67d5616a6fcd4c2abb3b48b039dd44a15012. You don't have to change anything inside your code, have fun and thanks for the feature request!

kataras avatar Apr 22 '18 12:04 kataras

You don't have to change anything inside your code, have fun and thanks for the feature request

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.

vividvilla avatar Jul 24 '18 12:07 vividvilla

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

kataras avatar Jul 25 '18 01:07 kataras