Re: Re: session_start read_only
Hi Andrey,
On Mon, Mar 24, 2014 at 3:21 AM, Andrey Andreev <[email protected]> wrote:
> On Sun, Mar 23, 2014 at 9:28 AM, Bill Salak <[email protected]> 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
[email protected]
Thread (4 messages)