Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70125
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: <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
References: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com>
 <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
Date: Fri, 15 Nov 2013 05:29:16 +0900
Message-ID: <CAGa2bXZ=jnFpi18ictXiJ1R2MLt--TLEz_p=hymPDMXmFS=CQQ@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3675ee2a50d04eb28f10c
Subject: Re: [PHP-DEV] Session cache, lock and write
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3675ee2a50d04eb28f10c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 15, 2013 at 4:59 AM, Adam Harvey <aharvey@php.net> wrote:

> 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 data is serialized. If content has changed, the data is changed.
Session could be large so I'm thinking using md5 hash to save memory.
Is there any better way?

> Session module could have ini settings
> >  - session.lock =3D On/Off (On by default. Some save handlers already h=
ave
> > 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 wo=
rried
> 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?
>

For files save handler, it should lock while reading/writing session data
at least.
Otherwise, there would be reader-writer issue. Thank you for point it out.

For other save handlers, author should take into concurrency.

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.
>

Right. Files save handler locks data, but mm save handler does not.
User save handler leaves locking to users.


> 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.


The behavior can be controlled by setting, so I would like to keep
single code files/mm/user and other save handlers.

I don't mind creating new handlers too much, but I'm concerned for having
multiple settings for each save handlers. (e.g. Memcached/MongoDB save
handler have it own lock setting. It would be better to have single setting
for any save handlers that support it.)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3675ee2a50d04eb28f10c--