Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
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: Fri, 15 Nov 2013 06:26:17 +0900
Message-ID: <CAGa2bXZjF_WVynzRyMRaF6XYC2DYYb36fO+nFp9cJ3MaaHbaZA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Adam Harvey <aharvey@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3c4fed6341104eb29bdbb
Subject: Re: [PHP-DEV] Session cache, lock and write
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3c4fed6341104eb29bdbb
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Fri, Nov 15, 2013 at 6:19 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > I think you've wrote this before I sent new mail. For files save handler,
> > when session.lock=Off, 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.
>
> > would not be a problem with write short circuit, since unchanged session
> > data is not written to session storage. User has to know what session
> > module is doing well to avoid problems, though.
>
> That's exactly the problem. Using this method would mean anything you
> write to a session can magically vanish and you wouldn't have any idea
> why, just because some other script was executing at the same time and
> have overwritten your data. "Read and never write" is OK, but read and
> then write without locking is very dangerous.


I agree.
This behavior could be dangerous just like SQL without transaction.
Therefore, only users know what they are doing should use.

It's dangerous, but if user know what they are doing, it could be safe and
application runs faster. This should be documented well. IMO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3c4fed6341104eb29bdbb--