Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73099
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAJ26g5TfiwjECNH_GbU6OCwCJdCCRJxKLUBL6wtw89XNo8P2eg@mail.gmail.com>
References: <CAPhkiZx=0Vr5p=7VZJD4PeD0ub-khSVMw3G03QhO8CC4xxm11A@mail.gmail.com>
 <CAGa2bXZTU5HzM4oXyiu0PnS=W2Oz1uLP_BnyWBUXyYUTO0tMYg@mail.gmail.com>
 <CAPhkiZz_d_wFPgwwYXJD-A+tz0Uf9KQ6uXNi1HhZGWFF1=W91A@mail.gmail.com>
 <CAGa2bXY86ri7b=rquo8Vbbh5ZoHOkwGBRoPWPup-SVPMu0WEgg@mail.gmail.com>
 <CAPhkiZyEqcx+UTPzpyYjz9pxWJnCNDO9pUMQNxvTpnrxmez9nw@mail.gmail.com>
 <CAGa2bXb5rLU26NDDHkWDw-FYf=vh2J=LAGFrqU3A3JJpOTY_dA@mail.gmail.com>
 <CAPhkiZyyXuqqybs+q8rnp_eJZDU0De2wMqwfv5mWiihr9GsueQ@mail.gmail.com>
 <CAGa2bXboo3CGOP9x+fW0Q98aniBcXejkGSJv5=qygL9ia67FbA@mail.gmail.com>
 <CAPhkiZzaTCE6sR=Rt=4VBmVOCo+uSQMREpf-fg6hWBrbCW+RXQ@mail.gmail.com>
 <CAGa2bXYWVoX_05BdS0M-V5G+B=4v-W-DPbWT8-vPrtd=gJtcCg@mail.gmail.com> <CAJ26g5TfiwjECNH_GbU6OCwCJdCCRJxKLUBL6wtw89XNo8P2eg@mail.gmail.com>
Date: Thu, 13 Mar 2014 16:45:17 +0900
Message-ID: <CAGa2bXbeucsEK2X1_wvtY_zMXs6guQAWxEMFhpjhyyOopq3sog@mail.gmail.com>
To: Patrick Schaaf <bof@bof.de>
Cc: internals <internals@lists.php.net>, Andrey Andreev <narf@devilix.net>
Content-Type: multipart/alternative; boundary=001a11c355b2d05a1c04f47824ed
Subject: Re: [PHP-DEV] Re: Revert session_serializer_name(), session_gc()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c355b2d05a1c04f47824ed
Content-Type: text/plain; charset=UTF-8

Hi Patrick,

On Thu, Mar 13, 2014 at 4:15 PM, Patrick Schaaf <bof@bof.de> 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
yohgaki@ohgaki.net

--001a11c355b2d05a1c04f47824ed--