Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70127
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <5285390D.6000106@sugarcrm.com>
Date: Thu, 14 Nov 2013 12:56:45 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Adam Harvey <aharvey@php.net>, Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com> <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
In-Reply-To: <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Session cache, lock and write
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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.

>> Session module could have ini settings
>>  - session.lock = 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 — 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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227