Re: Session cache, lock and write

Hi Stas, On Fri, Nov 15, 2013 at 6:19 AM, 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. > > > would not be a problem with write short circuit, since unchanged session > > data is not written to session storage. User has to know what session > > module is doing well to avoid problems, though. > > That's exactly the problem. Using this method would mean anything you > write to a session can magically vanish and you wouldn't have any idea > why, just because some other script was executing at the same time and > have overwritten your data. "Read and never write" is OK, but read and > then write without locking is very dangerous. I agree. This behavior could be dangerous just like SQL without transaction. Therefore, only users know what they are doing should use. It's dangerous, but if user know what they are doing, it could be safe and application runs faster. This should be documented well. IMO. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net