Re: session_start read_only

Hello, 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. > 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.