session_start read_only

Hi Andrey,

// $_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