Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tobin.nl designates 208.97.132.177 as permitted sender)
Message-ID: <52DCDDDB.70000@tobin.nl>
Date: Mon, 20 Jan 2014 09:27:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
In-Reply-To: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Introduce session.lock, session.lazy_write and
 session.lazy_destory
From: bas@tobin.nl (Bas van Beek)

Hi,

op 20-01-14 01:37, Yasuo Ohgaki schreef:
> Hi all,
>
> New session feature has been discussed while.
>
> Vote period: 2014/01/20 - 2014/01/30
> https://wiki.php.net/rfc/session-lock-ini
>
> New comments and questions are welcomed.

It's funny you mention the memcache session save handler. I remember 
when it was introduced quite some people were scratching their heads 
about unexpected session data behavior. Nothing in the module 
documentation even talked about it not locking the session data by 
default, therefore last script exiting writing it's version of the 
session data (where a script not changing the session data would write 
back the old session state removing other scripts' changes as it was 
just last to end. so much fun debugging non consistent session changes 
as a result of scripts ending in a different order).

I thought it was really bad behavior and complained about it then. The 
things you try to solve (concurrent access / speeding up performance) 
can for the most part already be done with the current session logic in 
a well defined consistent manner. opening and locking the session, 
reading and writing the needed session variables, closing and unlocking 
the session with session_write_close and continuing script execution 
after which other scripts have access to the session. For many 
programmers a familiar pattern similar to critical sections and mutexes 
in threaded environments.

I see only one very simple function potentially being helpful. A simple 
session close without write maybe called session_close(). This would 
give a performance bonus as it will not need to serialize the session 
data and write it back to session storage. It also helps to programmer 
in cases that he wants to guarantee that the session store is not 
changed by script (similar to a transaction abort).

just my $.02

Bas van Beek
> Thank you for voting.
>
> P.S. I have removed session_discard(). I've committed
> it as session_abort() to address FR last year. Name/alias
> is open to be changed. Please comment on different thread
> for this.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>