Hi!
>> I'm announcing the following RFC for discussion, with the hope that it
>> can get through before the PHP 5.6 release:
>> https://wiki.php.net/rfc/session-read_only-lazy_write
Frankly, I'm not sure what is the point of this - submitting RFC that
says "let's throw out RFC that we just accepted". If somebody didn't
want that RFC to happen, he'd vote against it, no?
I also don't understand what's the problem with read only option. Read
only option means only one thing - you're going to read the session, but
not write into it. Hence read only. Your scenario with login check is
not a problem because all session data are always read at the beginning
of the session. If another session changes the state later, it in any
case can not influence the session that have already read the data. The
only change is that now the session can say "I am not going to change
the state, nothing I am doing should change the state, so I'm not going
to waste my time on writing anything back".
Not allowing $_SESSION to be written sounds pretty useless to me, since
it is not going to be written anywhere anyhow, but this option does not
prevent implementing it in any way.
As for lazy_write, incomplete is not the reason to revert accepted
feature. Anything can be improved and amended, if we rejected features
because they could be improved, we'd never add anything. There is a use
case for this feature to exist, as an extension of the read only option
- it is a case where the session *might* change the state, but not
always does. So you have three options now:
1. My request is never going to change the state => use read_only
2. My request might change the state and thus I need exclusive lock =>
use lazy_write
3. My request always changes the state => use defaults
The difference between 1 and 2 is shorter period under lock, between 2
and 3 - saving time on transmitting data over the wire that are already
in session storage anyway. As for UPDATE_FUNC, I understand this is only
for updating "last used" if it exists and may be defaulted to nothing.
Again, nothing prevents us in PHP 6 from changing the defaults and
making this option part of the default option set.
>> As noted in it, I don't feel like
>> https://wiki.php.net/rfc/session-lock-ini was
>> handled properly. Lack
>> of attention to it alone is demonstrated by the fact that a total of
>> only 10 people have voted. I hope that this follow-up receives more
>> attention, so that we can avoid a potential mess.
>>
>
> "lazy_write" is not accepted. So you don't need to mention it in the RFC.
>
The vote result says "yes" on "Read only, lazy write option".
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227