Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71324
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Bas van Beek <bas@tobin.nl>, "internals@lists.php.net"
 <internals@lists.php.net>
In-Reply-To: <CAGa2bXZ8=XYE3kK8iBuwirb-u+OUTDve8USDzb8DaNSgMNvJcg@mail.gmail.com>
References:
	 <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
	 <52DCDDDB.70000@tobin.nl>
	 <CAGa2bXZ8=XYE3kK8iBuwirb-u+OUTDve8USDzb8DaNSgMNvJcg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Jan 2014 15:18:06 +0100
Message-ID: <1390227486.3439.134.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Introduce session.lock, session.lazy_write
 and session.lazy_destory
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Mon, 2014-01-20 at 17:42 +0900, Yasuo Ohgaki wrote:
> Hi Bas,
> 
> On Mon, Jan 20, 2014 at 5:27 PM, Bas van Beek <bas@tobin.nl> wrote:
> 
> > 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).
> >
> 
> I have already added this as session_abort().
> Since it's only in 5.6 and master branch, the name could be changed.
> However, session_abort() (or something like session_discard()) would be
> better name because the name implies it does not save data.
> 
> If you come up with better name, please let me know.

I think those two are useful:

  - session_abort() - close session, do *not* write, unlock file
  - session_close() - close session, *do* write, unlock file

I do think this also should be application defined, not configuration
defined. So using functions for that is better than ini options. Only
the individual script nows what it needs, global configuration for
tuning one application will break another on the same system and makes
it harder to write portable appliations.

johannes