Re: Session cache, lock and write

Hi Stas, On Fri, Nov 15, 2013 at 6:34 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > I agree. > > This behavior could be dangerous just like SQL without transaction. > > No, it is way, way more dangerous. SQL only changes the rows it touches, > session saves the whole session. It would be as if every SQL statement > would read whole database when you start the application, changed > something and then wrote the whole database - even the data you never > intended to touch - back to the disk, wiping out all the changes in all > other tables other applications changed since you have read it. Unlike > SQL, which operates only on small piece of data at a time usually, > session writes the whole thing in one bunch. There is no partial reads > in writes. So situation here is not even close to SQL - it is way worse. > The frame of breakage is much larger and the breakage is practically > guaranteed to occur. > > > 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. > > I don't think there's a user that knows that they are doing enough to > use such thing (because that means they have to know exactly how every > request in their app ever is serialized and what the exact timing of > every request is, now and forever in the future, and I do not see how it > is feasible). There might be ones that think they do, but that would be > a dangerous delusion, and I don't think we should support it. I agree your concern and I knew well what could be wrong since I forgot to set "serializable" transaction option when I made session_pgsql save handler. However, I think this feature would be nice as optional feature with BIG caution. I hope many users are used to "unlocked" session data already thanks to memcached/memcache/mongodb session save handlers. I'll make this a voting option. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net