Am 13.03.2014 02:41 schrieb "Yasuo Ohgaki" <[email protected]>:
>
> 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