Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71301
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
Message-ID: <52DCD1C5.8080109@sugarcrm.com>
Date: Sun, 19 Jan 2014 23:35:33 -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>
In-Reply-To: <CAGa2bXZxVGtFiVLnzCZ55cOY2qhoYnyvoi-MYB9ay1Pw5Dumiw@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!

> It allows access to old session for certain amount of time. 30 seconds
> would be enough for session.lock=off. 60 or more when session.lock=on.
> I was about to allow access to deleted session for 90 seconds.
> Configurable INI may be better. I'll make session.lazy_destroy a integer
> config.

It is irrelevant how long it is. Even 1 microsecond is long enough - if
the app said session data should be gone, then they should be gone, not
linger around and allow access to them. If you need access to that data,
copy it into the new session.

> IIRC you're one of them who are preferred to have separate
> implementation(?) 

I prefer not to have implementation for 2 out of 3 proposed "features"
at all, because I think they will produce more problems than solutions.
For the lazy-write feature, IMO it can be made global, or function (I
actually prefer both) - but I see no reason to create a duplicate
driver, if you don't want it turned on, turn off the option. I'm not
sure what would be the reason to clone the driver. Do you have a
reference for where it was asked so I could re-read it and recall what
were the reasons for it? My memory may be failing me :)

> No, they don't have to. They can ignore new features or implement them 
> all or part of them.

This would be a bit confusing - you set an option, but some drivers
would implement it, some would ignore it, so you never know what
actually happens.

> Shooting their own foot is possible, but let advanced users to enjoy 
> extreme performance!

I don't think performance at he expense of reliability, data consistency
and security should be our goal. Like I said, we could also make an
option to ignore random number of file writes and claim it is a
performance feature, but it would be useless, since there is no case
where one would recommend to use it. I see no case where I would
recommend anybody to use unlocked sessions - so why introduce it?

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227