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

From: Date: Thu, 13 Mar 2014 07:45:17 +0000
Subject: Re: Re: Revert session_serializer_name(), session_gc()
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi Patrick,

On Thu, Mar 13, 2014 at 4:15 PM, Patrick Schaaf <[email protected]> wrote:

> >
> > 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?)
>
Yes. This is issue for save handlers that should perform costly GC.

> > 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)
>
I agree. It's proper and feasible solution. I've sent issues about
session_regenerate_id() in other thread. It could be solved by time stamp
stored as session data also. Storing time stamp out side of $_SESSION data
would be cleanest solution, but it requires new interface.

It may be good idea to write a new save handler interface while keeping
older one.

Regards,

--
Yasuo Ohgaki
[email protected]


Thread (41 messages)

« previous php.internals (#73099) next »