Re: Re: Revert session_serializer_name(), session_gc()

Am 13.03.2014 02:41 schrieb "Yasuo Ohgaki" <yohgaki@ohgaki.net>: > > Save handler may keep & check last GC time. If it's over session.expire, > perform GC. That would have a "scoping" problem: session.expire, at least in theory, can be different for different scripts / usages of session in the same application, but such a global last-GC timestamp would be... global. Also generally GC is a costly global operation, slowing down the request that hits it (probably that's why you envision a cronjob right?) > Issue is that "session data that should be deleted" is not deleted and > could be alive long term due to current design. Current design is good The _proper_ solution, would be to keep a timestamp stored with each session. kind of a last-modified timestamp. (expiry does work off last modification, right?). Anyhow, the trick is to check at session_start whether that timestamp plus whatever session.expire is set at, already is in the past - and when that happens, destroy the one session on storage and act as if it hadn't been found. This way there is no longer any correctness problem, and a GC is only needed to clean up sessions that are never requested again - and for that I fully agree that a separate - e.g. cron driven - "GC now" job would be best (not affecting latency of running frontent requests too much). Of course, going to such a solution, requires a change to all session implementations in that they must provide for storage and return of such a last-modified timestamp (or othewise the improvement cannot be realized for a non-updated-to-the-new-scheme session handler) best regards Patrick