Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70129
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <5285390D.6000106@sugarcrm.com>
References: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com>
 <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com> <5285390D.6000106@sugarcrm.com>
Date: Fri, 15 Nov 2013 06:12:34 +0900
Message-ID: <CAGa2bXZ99mW003=wZ021gNUxVJ3z6KxUUYMUYJh3QdiDEwQFRA@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=001a11c3ca10cde21a04eb298c7f
Subject: Re: [PHP-DEV] Session cache, lock and write
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3ca10cde21a04eb298c7f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Stas,

On Fri, Nov 15, 2013 at 5:56 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:

> > How do you propose to check if session data was changed? For scalar
>
> I think the best way is not to check, but to let the user tell you.
> I.e., I often found it useful to have some way to load session data, but
> then to drop the lock and not write anything. It may be useful for
> application which keeps the state in the session but changes the state
> rarely and only in some well-defined points - e.g. when the app is
> authorized (needs session for auth state) but only login/logout actually
> change this state. That would reduce network traffic by such app for
> session storage by almost 2x, even ignoring the fact that writes are
> usually more expensive than reads on the server end.


We need new user function that close session and does not write session
data. Current session module writes session data always. I'll add that.

session_close() - Close session and discard data.



>  >> Session module could have ini settings
> >>  - session.lock =3D On/Off (On by default. Some save handlers already =
have
> >> this)
> >
> > I've got some concerns on this. I agree that it's a real issue =E2=80=
=94 we do
>
> We could have read-with-no-lock semantics, but taking into account the
> above it's almost the same as read-with-lock+release-lock semantics, and
> given the protocols for some storage engines, may internally probably do
> exactly the same. Convenience function though may be useful.
>
> read-with-no-lock + write however is very dangerous proposition and I
> don't think we should support that - it makes, as you correctly pointed
> out, shooting oneself in the foot extremely easy.
>
> Which means for me that INI setting doesn't make a lot of sense, since
> you dont want ALL of your sessions be read-only - you need to write
> something to read something - and write without locks is a nightmare.


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

There may be race for writing, but full data is written to data file.

Current behavior is

open-and-lock -> read session data
script executed
-> write session data -> close-and-unlock

Therefore, other script execution is blocked until lock is released.
(i.e. call session_commit() or script execution ends as you already knew.)

New behavior
=3D=3D=3D=3D=3D=3D
open-and-lock -> read session data -> close-and-unlock ->
script executed
-> open-and-lock -> write session data -> close-and-unlock
=3D=3D=3D=3D=3D=3D
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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3ca10cde21a04eb298c7f--