Re: Session cache, lock and write

From: Date: Thu, 14 Nov 2013 21:33:40 +0000
Subject: Re: Session cache, lock and write
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-70136@lists.php.net to get a copy of this message
Hi Adam and Stas, On Fri, Nov 15, 2013 at 6:25 AM, Adam Harvey <aharvey@php.net> wrote: > On 14 November 2013 13:19, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > >> I think you've wrote this before I sent new mail. For files save > handler, > >> when session.lock=Off, it will be > >> > >> open-and-lock -> read session data -> close-and-unlock -> > >> script executed > >> -> open-and-lock -> write session data -> close-and-unlock > > > > I don't think this is a very good idea, since what happens if somebody > > else changed the state while script was executing? That change would be > > killed by the write. The lock is not for writing, the lock is for data > > consistency between reading in writing. If you gave up the lock, you > > should not write afterwards because your data may be stale. > > I can see situations where that might be useful — where it's not so > important if the write gets clobbered so long as there's minimal > locking to ensure that the session file is at least valid. > > I'm still on the fence about whether it's actually a useful thing to > support in php-src, though. It might be enough of a corner case to not > make it worth supporting in a bundled session handler, and I'm worried > the people might start giving advice that using it will "speed up your > application" and users who copy-paste configurations will silently > usedata. > > As an aside, if we do implement it: Yasuo, you've convinced me that > session.lock is a reasonable name (instead of being handler-specific). > :) Memcached/Memcache/MongoDB session save handlers already have lock option. I think not few users are used to it already. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#70136) next »