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

Hi Andrey, 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, -- Yasuo Ohgaki yohgaki@ohgaki.netsession_start();session_commit()