Re: Session cache, lock and write

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 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? 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. 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. Adam