Hi Andrey,
On Fri, Mar 14, 2014 at 7:07 PM, Andrey Andreev <[email protected]> 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
[email protected]_start();session_commit()