Re: Session cache, lock and write

On Fri, Nov 15, 2013 at 4:59 AM, Adam Harvey <aharvey@php.net> wrote: > On 14 November 2013 11:42, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > It can ignore writing session data when session data is not changed. > > It also can remove reading session data by caching as most web > > servers support keep alive. Current session save handlers lock > > session data, but it could be unlocked. > > How do you propose to check if session data was changed? For scalar > types it's pretty easy, but it's possible for objects to alter their > properties (including the ones they're persisting) on __wakeup() — I > presume it would effectively be a comparison of what's about to be > written versus what was read initially when it comes time to write the > session? > Session data is serialized. If content has changed, the data is changed. Session could be large so I'm thinking using md5 hash to save memory. Is there any better way? > Session module could have ini settings > > - session.lock = On/Off (On by default. Some save handlers already have > > this) > > I've got some concerns on this. I agree that it's a real issue — we do > get support issues in ##php caused by people attempting to > concurrently access open file sessions, for instance — but I'm worried > that this might be a shoot-yourself-in-the-foot option if we're not > careful. I'm thinking mostly of the files handler here: I presume > there would still be locking around initial read and write operations? > For files save handler, it should lock while reading/writing session data at least. Otherwise, there would be reader-writer issue. Thank you for point it out. For other save handlers, author should take into concurrency. Also, as you note, there also isn't any requirement for session > handlers to implement locking right now: if I'm implementing a custom > session handler that doesn't require locking, do I just ignore this > setting if it's not relevant? It seems slightly odd having it in the > session.* namespace if it's really only relevant for files. > Right. Files save handler locks data, but mm save handler does not. User save handler leaves locking to users. > I wonder if a better approach would be to implement an improved files > handler (under a different name) that had options for locking, caching > and the like. Say it was called "awesome_files"[0]; you might have > options like this: > > session.save_handler = awesome_files > session.awesome_files.lock = On/Off > > I'd love to have a more flexible files handler, but I don't think we > want to overspecialise the session implementation around it. The behavior can be controlled by setting, so I would like to keep single code files/mm/user and other save handlers. I don't mind creating new handlers too much, but I'm concerned for having multiple settings for each save handlers. (e.g. Memcached/MongoDB save handler have it own lock setting. It would be better to have single setting for any save handlers that support it.) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net