We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
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
Implement new Symfony 3.4+ session handler to gain session fixation protection and avoid unnecessary writes.
This breaks compatibility with Symfony 3.3 and below so it should be included in a major version only IMO, but we are going to use it in production soon.
Note that this includes #403 as I didn't want to introduce conflicts but I can easily undo that if needed.
Also note that with this, as Symfony will only write to the session when data actually changed, locking the session becomes a lot less necessary, as you have less chances of overwriting data with outdated one. At least if you don't use the session too much this is a big win in terms of throughput and number of commands redis has to deal with.
So:
session: client: session ttl: 3600 locking: false
Sorry, something went wrong.
Implement new Symfony 3.4+ session handler to gain session fixation p…
83cb3df
…rotection and avoid unnecessary writes
e096210
Thank you so much for this feature! Is there any plan to release a next major including this? Could we have any roadmap for it? It will bring a great performance impact, so I'm waiting to be able to implement this within a stable release.
There are a few things left before 3.0 stable can be tagged https://github.com/snc/SncRedisBundle/milestone/2 - it should be relative safe to require 3.0-dev though, we try to keep things stable.
Thing is that there's the major breaking change coming up to "fix phpredis logging". It'll be a biggie as it involves generating proxies and switching logging to an event listener instead of explicit. Once that one's done it'll mostly imply the other pending changes for 3.0 (reorganize services, private service locators etc.).
We could tag 3.0.0-alpha.1 or something I suppose, at least then you'll be safer than on master branch.
3.0.0-alpha.1
Successfully merging this pull request may close these issues.