Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73497
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZyub+HiJAYbChQJkCfn1J0dmHcpwGV_R5_fxiXzUaFxiw@mail.gmail.com>
References: <002f01cf4669$6e3b1570$4ab14050$@devtemple.com> <CAPhkiZyub+HiJAYbChQJkCfn1J0dmHcpwGV_R5_fxiXzUaFxiw@mail.gmail.com>
Date: Tue, 1 Apr 2014 15:18:48 +0900
Message-ID: <CAGa2bXZtx+bSEZdTH-7nuviDCCHWgjXMcC_a+4i8jCjJMSbNgA@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Bill Salak <bill@devtemple.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0118294e79f71504f5f52615
Subject: Re: [PHP-DEV] Re: session_start read_only
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0118294e79f71504f5f52615
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Mon, Mar 24, 2014 at 3:21 AM, Andrey Andreev <narf@devilix.net> wrote:

> On Sun, Mar 23, 2014 at 9:28 AM, Bill Salak <bill@devtemple.com> wrote:
> > // $_SESSION['logged_in'] has been set in a previous request
> > Request 1: session_start(['read_only' => TRUE]);
> > Request 2: session_start(); unset($_SESSION['logged_in']);
> session_write_close();
> > Request 1: if ($_SESSION['logged_in']) { /* logic */ } // evaluates to
> TRUE
> >
> > works the same way today that you describe as a problem, if I'm not
> mistaken.
> >
> >  - Request 1 locks the session and Request 2 waits.
> >  - Request 1 finishes and unlocks the session.
> >  - Request 2 can now get on with its work.
>
> My example shows that Request 1 completes after Request 2, and that's
> not the same thing. There were already multiple comments on that
> example and it turned out not to be as clear as I thought. I'm working
> on an updated version of the RFC, which would also provide a better
> example.
>

Net result is the same.
Besides, we already have session_commit()/session_write_close().

 > I initially suggested this "read_only" feature to Yasuo (as he has
> implemented it today) in order to solve this blocking wait time problem.
> The use case I wanted a solution
> > for is common in the applications I design/work-on/see today which is
> modular AJAXy/independent access to PHP sessions, i.e. "is this user logged
> in and allowed to call this thing?"
> > In these use cases I often know I just need to read the session data and
> will not write to it therefore I just want the lightest, quickest
> read-and-release-session process possible for
> > near-concurrent access to reading the session. Actually writing+reading
> to a session (or any datastore for that matter) becomes a synchronicity
> issue which is fundamentally at odds
> > with a codebase designed around asynchronous access to state and needs
> to be solved for by the application architecture/design in those situations
> that need to have that sort of
> > protection. In other words, I believe the example problem use case
> you've posed is an application design problem not a language level issue
> IMO.
>
> It is a design problem, but the 'read_only' name is highly misleading
> (especially for an option to session_start()), which is a language
> (design) level issue. It's a nice feature, but should be accessible
> through better API.
>

It's good enough name. IMO. I renamed it to "read_and_close", though.

read_only (or read_and_close) - Read and initialize $_SESSION, then close
session immediately.

It wouldn't cause much trouble. AFAIK, you think it's misleading.
What others think?

 > On a related note, your suggestion of a "true read only" implementation
> would presumably either throw an error on attempt to write to a session
> that was locked as "read only" or
> > would act as sessions act today, which is to say, wait for the session
> to unlock before writing to it. My gut reaction is that neither of these
> are better than what we have today but
> > the conversation is young and I'm interested to hear more.
>
> That's a description of what the "read-only" term means, and hence -
> why naming the current feature "read_only" is misleading. Whether
> "true read only" is implemented or not is not what I'm interested in
> right now, I'm not pushing for it.
>
> > One last point, the ability to "configure" a session through an array of
> options is very useful from an end-user code design point-of-view. Moving
> the ability to start a session as read
> > only to a separate function call than I would use to start a session
> otherwise forces choices in code design that can otherwise be much more
> elegantly handled through the use
> > of a single function with a configuration parameter.
>
> I love the ability to pass options to session_start(). :)
> What I don't like is that session_start($options) could mean that the
> session is closed immediately, it's counter-intuitive.


Option name is better to be descriptive, but it's better to be short enough.
With proper documentation, there wouldn't be confusion. This is what the
documentation is for.

read_only option is really useful option as
"session_start();session_commit();" is
common performance optimization technique for more than 10 years. There
would be
"session_start();session_abort();" for new PHP to do the similar job, but
it does
not look nice. (session_abort() is for preventing write when something
wrong, i.e.
errors, had happened)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0118294e79f71504f5f52615--