Re: session_start read_only
Hello,
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.
> 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.
> 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.
Cheers,
Andrey.
Thread (4 messages)