A drop-in replacement for PHP's default session handler which stores session data in a MySQL database, providing better performance, better security and protection against session fixation and session hijacking
Hello!
We adopted Zebra Sessions to our project and it was working flawlessly, just like file-based sessions.
We came up with the idea, that some of the requests do not change $_SESSION data at all, but still require to read session data. Session does not have to be locked for read access.
Reasoning behind this is that our web application generates a lot of background requests to the backend. Application architecture assumes that all requests are stateful, therefore session is locked (session_open()) for the whole processing time, so there won't be any concurrent changes in $_SESSION. Downside being that this prevents users from accessing application while another request is being processed.
Please review proposed changes. Since we're using MySQLas backend, the changes are quite small. The idea is to bypass locking (GET_LOCK) part if session is set to R/O mode and not saving (INSERT) data at all. Once R/O session is opened it cannot be changed to R/W to avoid save/update conflicts. The SELECT part (reading session data) is unaffected and returns session data available at the moment of request.
We have tested and deployed this solution, it's running without issues on production deployments for some time now.
stefangabos
commented
4 years ago
Hello! We adopted Zebra Sessions to our project and it was working flawlessly, just like file-based sessions.
We came up with the idea, that some of the requests do not change $_SESSION data at all, but still require to read session data. Session does not have to be locked for read access.
Reasoning behind this is that our web application generates a lot of background requests to the backend. Application architecture assumes that all requests are stateful, therefore session is locked (session_open()) for the whole processing time, so there won't be any concurrent changes in $_SESSION. Downside being that this prevents users from accessing application while another request is being processed.
Please review proposed changes. Since we're using MySQLas backend, the changes are quite small. The idea is to bypass locking (GET_LOCK) part if session is set to R/O mode and not saving (INSERT) data at all. Once R/O session is opened it cannot be changed to R/W to avoid save/update conflicts. The SELECT part (reading session data) is unaffected and returns session data available at the moment of request. We have tested and deployed this solution, it's running without issues on production deployments for some time now.