Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52E9A631.5050808@sugarcrm.com>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
 <CAGa2bXZTMDQffTNF5G_N9s9qqzkD0188+jAZ5JAqoraxbKwjHQ@mail.gmail.com> <52E9A631.5050808@sugarcrm.com>
Date: Thu, 30 Jan 2014 12:01:39 +0900
Message-ID: <CAGa2bXYn8i9R2+FGMUeyrr00MjRMug5QhheLa=gLKSOc+0j-CA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136c74223a97604f127493b
Subject: Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1136c74223a97604f127493b
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Thu, Jan 30, 2014 at 10:09 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> 6 options seems too much. 0 shouln't even be a vote - if people want
> specific options, then ipso facto they want them introduced, and
> parameter is a way to do it, if none is accepted - there's no reason to
> introduce the parameter. I would rather make it part of the whole
> proposal and propose both INI value and session_start options (with the
> latter overriding the former).
>
> Proposal 5 seems to have nothing to do with the rest. So it probably
> needs to be split out.
>
> I'd just leave it as two proposals (this is my personal preference):
>
> 1. Options & read_only + lazy_write (these ones seem to be least
> controversial ones and don't seem to have any negative implications)
> 2. lazy_destroy
> 3. minimize_lock if you really want it though I still think it is
> dangerous and is not needed if read_only and lazy-write exist and if you
> still need it you're doing sessions wrong. But if you really think
> there's a case then let's put it as separate one.
>
> So we'd have 2 or 3 options, which I think is the max for vote to be
> manageable.
>

Sounds reasonable. I'll update RFC according to your comment.

minimize_lock is still useful for users would like to write only when
$_SESSION
is updated. Without it, session data is locked and scripts are not executed
in
parallel. Programmer has to selectively start session read only and
re-start
session for writing when it's needed. Efficient session management could be
done as I wrote/you think, so it's not strictly required.

'minimize_lock' make things easier (no selective read only session nor
re-starting session for writing) for experts  when consistency is under
control.


Some more things:
> - session_unlock - I don't see how it's different from session_abort.
> What's the need for it?
>

I should have change this description.

session_abort() closes session without writing data.
session_unlock() unlock session data. Data is written when
session_commit()/etc.

session_unlock() is not needed if there is 'minimize_lock'. Unlike
'minimize_lock',
it will slow down performance. It will not be implemented.


>  - session_module_feature - what is the use case for it? I'm not sure I
> understand why anybody would use it. Especially if outputs would be
> non-machine-friendly as "Partially Supported" - what would you do with
> that? What Partially means here?
>

This is informational function for programmers, not for programs.
It requires active session to be useful because it needs active save handler
module. It's rather suitable as phpinfo(), but it might not be useful for
users.
Since

<?php
session_module('foo');
// or define/load user save handler and set it
session_start();
phpinfo()
?>

is required to be useful. It may return result as constants. I'm not sure
if it is useful. If anyone insists, I'll change it return constants.

Meaning of "Partially Supported" depends on save handler. It should be
documented in save handler manual what does it mean. For example,
session_gc() with file handler works for single directory, but it's not for
multiple directory. We had number of not-a-bug reports for this.

I would like to reopen vote next week.
Anyone who has comments, please send them now.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1136c74223a97604f127493b--