Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73098
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYWVoX_05BdS0M-V5G+B=4v-W-DPbWT8-vPrtd=gJtcCg@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>
Date: Thu, 13 Mar 2014 08:15:00 +0100
Message-ID: <CAJ26g5TfiwjECNH_GbU6OCwCJdCCRJxKLUBL6wtw89XNo8P2eg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: internals <internals@lists.php.net>, Andrey Andreev <narf@devilix.net>
Content-Type: multipart/alternative; boundary=001a11c120622827ef04f477b6f9
Subject: Re: [PHP-DEV] Re: Revert session_serializer_name(), session_gc()
From: bof@bof.de (Patrick Schaaf)

--001a11c120622827ef04f477b6f9
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c120622827ef04f477b6f9--