Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
Hi,
op 20-01-14 01:37, Yasuo Ohgaki schreef:
It's funny you mention the memcache session save handler. I remember when it was introduced quite some people were scratching their heads about unexpected session data behavior. Nothing in the module documentation even talked about it not locking the session data by default, therefore last script exiting writing it's version of the session data (where a script not changing the session data would write back the old session state removing other scripts' changes as it was just last to end. so much fun debugging non consistent session changes as a result of scripts ending in a different order).
I thought it was really bad behavior and complained about it then. The things you try to solve (concurrent access / speeding up performance) can for the most part already be done with the current session logic in a well defined consistent manner. opening and locking the session, reading and writing the needed session variables, closing and unlocking the session with session_write_close and continuing script execution after which other scripts have access to the session. For many programmers a familiar pattern similar to critical sections and mutexes in threaded environments.
I see only one very simple function potentially being helpful. A simple session close without write maybe called session_close(). This would give a performance bonus as it will not need to serialize the session data and write it back to session storage. It also helps to programmer in cases that he wants to guarantee that the session store is not changed by script (similar to a transaction abort).
just my $.02
Bas van Beek
Thank you for voting.
P.S. I have removed session_discard(). I've committed
it as session_abort() to address FR last year. Name/alias
is open to be changed. Please comment on different thread
for this.
--
Yasuo Ohgaki
[email protected]
Thread (42 messages)