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

From: Date: Mon, 17 Mar 2014 00:09:19 +0000
Subject: Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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.

Regards,

--
Yasuo Ohgaki
[email protected]


Thread (34 messages)

« previous php.internals (#73200) next »