Re: Re: session_start read_only

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