Re: Session cache, lock and write
| From: | Yasuo Ohgaki | 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