note 110352 deleted from function.session-set-save-handler by danbrown

Note Submitter: sven at rtbg dot de ---- Be aware that reading and writing a session requires locking! The internal save handlers are supposed to do the locking, and at least the "files" save handler works in this respect. Unfortunately this documentation does not mention the fact that not locking can lead to destroyed session data. Please test the code at http://pastebin.com/EbqigxmY - it uses the code from example #2 on this page to show what not locking sessions can do. Expected behaviour is that all three iframes will be filled one after another with a 1 second break between every response. The last response should list all three requests and the master request. Actual behaviour is that all iframes are filled in parallel, and every single one dumps only the master request and itself. If you implement your own session save handler, never forget the locking! That's what the callbacks for "open" and "close" are for. You need an exclusive write lock from the start, otherwise a parallel request will be able to read stale data and overwrite the changes made. Yes, this costs performance, or more precisely this will serialize all requests that start the session. There are basically two methods to improve this: 1. Call session_write_close() as early as possible in every script. 2. You might implement two session handlers, one for reading and writing (including locking), and another one only for reading. If you never write back, there is no need for a lock, provided that at the time you read, no other write process interferes.