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

Hi, On Mon, Mar 17, 2014 at 2:09 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Mon, Mar 17, 2014 at 8:07 AM, Andrey Andreev <narf@devilix.net> 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?