Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70133
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.219.44 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <52853E69.5040104@sugarcrm.com>
References: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com>
 <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
 <5285390D.6000106@sugarcrm.com> <CAGa2bXZ99mW003=wZ021gNUxVJ3z6KxUUYMUYJh3QdiDEwQFRA@mail.gmail.com>
 <52853E69.5040104@sugarcrm.com>
Date: Thu, 14 Nov 2013 13:25:00 -0800
Message-ID: <CADajX4CMO=J3ij7qCGybtQ+33OtsYxaGiJxETSMuHXAKUw6uiQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "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 13:19, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> I think you've wrote this before I sent new mail. For files save handler=
,
>> when session.lock=3DOff, it will be
>>
>> open-and-lock -> read session data -> close-and-unlock ->
>> script executed
>> -> open-and-lock -> write session data -> close-and-unlock
>
> I don't think this is a very good idea, since what happens if somebody
> else changed the state while script was executing? That change would be
> killed by the write. The lock is not for writing, the lock is for data
> consistency between reading in writing. If you gave up the lock, you
> should not write afterwards because your data may be stale.

I can see situations where that might be useful =E2=80=94 where it's not so
important if the write gets clobbered so long as there's minimal
locking to ensure that the session file is at least valid.

I'm still on the fence about whether it's actually a useful thing to
support in php-src, though. It might be enough of a corner case to not
make it worth supporting in a bundled session handler, and I'm worried
the people might start giving advice that using it will "speed up your
application" and users who copy-paste configurations will silently
usedata.

As an aside, if we do implement it: Yasuo, you've convinced me that
session.lock is a reasonable name (instead of being handler-specific).
:)

Adam