Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71311
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: <52DCE356.5040600@sugarcrm.com>
Date: Mon, 20 Jan 2014 00:50:30 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com> <52DC905F.2080705@sugarcrm.com> <CAGa2bXbrr3CreZoaasDFWebSG-f4ai-AcTEiX9BGXZLTvjjb+Q@mail.gmail.com> <52DCAE75.8070401@sugarcrm.com> <CAGa2bXZxVGtFiVLnzCZ55cOY2qhoYnyvoi-MYB9ay1Pw5Dumiw@mail.gmail.com> <52DCD1C5.8080109@sugarcrm.com> <CAGa2bXZbrGVJxHZNKNee-jgj19XGd8_YOWJ8ufb6mNd-qJkkOg@mail.gmail.com>
In-Reply-To: <CAGa2bXZbrGVJxHZNKNee-jgj19XGd8_YOWJ8ufb6mNd-qJkkOg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Introduce session.lock, session.lazy_write and
 session.lazy_destory
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> In previous mail, it is described good use case.
> Without locking, scripts are executed concurrently. 

If the scripts are going to write the session, they can not execute
concurrently, because that creates race condition and at least one of
the states will be lost. If they don't intend to write, they can just
drop the lock immediately after reading, that's why we talked about
having function for that. Neither works well with no locks at all.

> When session.lock=off and session.lazy_write=on, scripts does not have
> to wait session read() and only updated session is written back to storage.
> For example, if session only store authentication information, it works 
> perfectly and there is no risk of authenticated(logged out session) remains

It doesn't work perfectly for scripts that modify authentication
information. And writing an app where there are race conditions in
authentication mechanism is very poor idea, security-wise. For
performance in read-only case, there's a simple solution which does not
jeopardize stability, see above.

> We also should consider that memcache/memched have unlock option already.

I would not recommend anybody then to use them with that option. This
only can lead to trouble. It's running shared data structure without any
locks. If it's not specially designed for it, you'll get in trouble -
and it will always be undebuggable, unreproducible and happen in the
worst possible moment, when the system is loaded and too many things are
happening at once.

> Like databases allow query without transaction or transaction with less 

If you are using DB without transactions, you must ensure consistent
state in your app, or accept data inconsistency. Data inconsistency may
be ok if your data is not that important - but if it's
security-sensitive, it is not a good idea. Sessions usually deal with
security-sensitive data.

> I'll write clearly that "end users" should never enable dangerous
> options unless
> developer explicitly allows it. I'll also write that developers are

I don't think we should provide options that need disclaimers that say
"do not use it unless in very rare cases". If you are experienced enough
that you need this rare case, you can implement your own session handler
that does that. Especially given that the only use case I have seen so
far actually does not need this feature and works just fine with much
safer and smaller feature (session unlock, aka session_discard, aka
session_abort).
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227