Re: Re: Revert session_serializer_name(), session_gc()

On Fri, Mar 14, 2014 at 7:30 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > On Fri, Mar 14, 2014 at 7:07 PM, Andrey Andreev <narf@devilix.net> wrote: > >> This is broken, consider the following (multiple tab/ajax/whatever >> concurrency) scenario: >> >> Request1: session_start(['read_only' => TRUE]); >> Request2: session_start(); unset($_SESSION['logged_in']); >> session_commit(); >> Request1: still logged in >> >> ^ This screams "danger". >> > > I think all of us know what it does. > > >> >> It's also, redundant ... do you really believe you'd get +1 votes for >> that feature if the voters were *really* aware that this would be just >> an alias for (sesson_start() && session_commit()) ? >> > > It's not alias. It's much more efficient. > > >> I don't think so. This is simply not what "read only" means which >> makes this whole thing very misleading and if people who were supposed >> to review the feature got confused by it, imagine what happens in >> userland. >> > > I might not explain well enough in the RFC, but most of use understood > it's a faster version of session_start();session_commit(). > > Calling session_commit() right after session_start() is common > optimization technique. Making it more efficient worth it. > > I think there is no point to write back to the session data while > programmer only needs to read the data. Since > session_start();session_commit(); is optimization technique, making it more > efficient makes sense. > > Regards, > Pressed send button before re-reading. I think it could be understood what I mean. -- Yasuo Ohgaki yohgaki@ohgaki.net