Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69820
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAJ26g5TzN4T9m54bmygKZWOMThFzzJb8XwtoL4a7kO9X=EAkpw@mail.gmail.com>
References: <CAGa2bXbNFb0tV+Xqavz9m62RDxobey3BmyN0L7g9ATFxMS_KBA@mail.gmail.com>
 <CAH-PCH7TbexgCAVphaC_H8AF-V5UfNysy863Gq1sOzkxgQ01XA@mail.gmail.com>
 <CAJ26g5QH4j3K2peF7rGO-2uO_mjBK4kQELXCBQVXJOe9A7UEsw@mail.gmail.com>
 <CAGa2bXZRD_DKvrXy1gdesxbnNK+n8vVKT1K=P4ocU=m9aZMX2A@mail.gmail.com> <CAJ26g5TzN4T9m54bmygKZWOMThFzzJb8XwtoL4a7kO9X=EAkpw@mail.gmail.com>
Date: Thu, 24 Oct 2013 08:59:06 +0900
Message-ID: <CAGa2bXbjhZd9EAeUs3dQzcroZ_Sf0TE_w5xsHMuh86wZufixoQ@mail.gmail.com>
To: Patrick Schaaf <bof@bof.de>
Cc: internals <internals@lists.php.net>, Ferenc Kovacs <tyra3l@gmail.com>
Content-Type: multipart/alternative; boundary=089e0158c432caabfc04e9714f89
Subject: Re: [PHP-DEV] session_regenerate_id(true) by default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0158c432caabfc04e9714f89
Content-Type: text/plain; charset=UTF-8

Hi Patrick,

On Wed, Oct 23, 2013 at 4:35 PM, Patrick Schaaf <bof@bof.de> wrote:

> While true for us, that is a separate issue. The parallel in-flight
> requests meeting an invalidated session, will happen as well with fully
> locked sessions - for example they will wait on the lock for the old
> session ID while the regenerating script is still before the regeneration
> point. When the lock is lifted (with regenerate(true)) they will then see
> an empty session, potentially affecting their operation due to missing
> context.
>
> Regarding non-full session locking, going that way is a conscious decision
> for us. We find that most of the time the session data we use is readonly,
> i.e. a once set up set of contextual information is used but not modified
> by e.g. additional ajax requests. Full locking in these cases, coupled with
> the occasional longer running script, results in full serialization of
> request processing, which translates into much increased total latency for
> the end user.
>
> Thus, our general approach is to shortly open the session, capturing
> $_SESSION to class static storage, and closing the session again. Setter
> methods of our helper class then maintain a dirty flag, and at the end of
> the script run (or explicitly called), a "flush" method examines that dirty
> flag, and only when dirty, it opens the session again and replaces all
> session variables with the full set of variables modified by that script
> (so no modifications of several parallel scripts are mixed together -
> simple last-one-wins, which makes reasoning about correctness somewhat
> easier).
>
I can make deletion of old session data at the end of request (i.e. delete
old session data at RSHUTDOWN) by keeping deleted session id in a hash.
Hash or any other storage is required since users can call
session_commit()/session_write_close() and call session_start() again, then
call session_regenerated_id()/session_destory(). Deleting session data at
RSHUTDOWN  would leave time read old session data for multiple requests at
the same time.

session_start() - locks session data
session_regenerate_id() - release lock for old session data and stores id
to a hash to delay deletion.
RSHUTDOWN - check hash and if there is session data to be deleted, delete
them.

It may be good idea to have short wait time (configurable, 100
topms or so by default) and/or get lock for the deletion so that give
better chance to have non-empty session data.

Simple applications don't have to care much but complex apps may have race.
 I'll try to see if this idea works well or not.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0158c432caabfc04e9714f89--