Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions

From: Date: Mon, 17 Mar 2014 08:52:51 +0000
Subject: Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi,

On Mon, Mar 17, 2014 at 2:09 AM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Andrey,
>
> On Mon, Mar 17, 2014 at 8:07 AM, Andrey Andreev <[email protected]> wrote:
>>
>> >> "last used", "last updated", "last modified",
>> >> "last accessed" ...
>> >> however you call it, it always exists in some form. Without such a
>> >
>> > Last used and last modified are very different things. Nothing prevents
>> > one from tracking either. We need to check it is done properly and is
>> > compatible with old handlers, but it should be entirely possible to do
>> > it in a BC way.
>>
>> See, this is what I meant with 'read_only' it may be a name closely
>> explaining what it does, but in fact it has an essentially different
>> meaning. :) The session module only uses one of those timestamps is
>> what I meant here. And it may be possible to handle that in a BC way,
>> but the RFC doesn't mention if that's really the case and/or how it
>> could be done - this is stuff that must be addressed.
>
>
> It updates time stamp always.
>
> It does
>
> "write data if data is updated"
> or
> "write data if save handler does not have update API"
> or
> "update time stamp if it is needed" (e.g. memcache does not need to update
> time stamp since it updates time stamp by read. It's save handler
> implementation choice what to do with update API)
>
> For save handlers like memcahe/memcached, session module is writing back the
> same data just to waste resources when session data hasn't changed.

And what about userland session handlers?


Thread (34 messages)

« previous php.internals (#73203) next »