Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70123
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.219.50 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com>
References: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com>
Date: Thu, 14 Nov 2013 11:59:32 -0800
Message-ID: <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Session cache, lock and write
From: aharvey@php.net (Adam Harvey)

On 14 November 2013 11:42, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> It can ignore writing session data when session data is not changed.
> It also can remove reading session data by caching as most web
> servers support keep alive. Current session save handlers lock
> session data, but it could be unlocked.

How do you propose to check if session data was changed? For scalar
types it's pretty easy, but it's possible for objects to alter their
properties (including the ones they're persisting) on __wakeup() =E2=80=94 =
I
presume it would effectively be a comparison of what's about to be
written versus what was read initially when it comes time to write the
session?

> Session module could have ini settings
>  - session.lock =3D On/Off (On by default. Some save handlers already hav=
e
> this)

I've got some concerns on this. I agree that it's a real issue =E2=80=94 we=
 do
get support issues in ##php caused by people attempting to
concurrently access open file sessions, for instance =E2=80=94 but I'm worr=
ied
that this might be a shoot-yourself-in-the-foot option if we're not
careful. I'm thinking mostly of the files handler here: I presume
there would still be locking around initial read and write operations?

Also, as you note, there also isn't any requirement for session
handlers to implement locking right now: if I'm implementing a custom
session handler that doesn't require locking, do I just ignore this
setting if it's not relevant? It seems slightly odd having it in the
session.* namespace if it's really only relevant for files.

I wonder if a better approach would be to implement an improved files
handler (under a different name) that had options for locking, caching
and the like. Say it was called "awesome_files"[0]; you might have
options like this:

session.save_handler =3D awesome_files
session.awesome_files.lock =3D On/Off

I'd love to have a more flexible files handler, but I don't think we
want to overspecialise the session implementation around it.

Adam