To further comment, the default behavior of the module is frequently wrong.
If there are two simultaneous requests that use the same session then:
1. Process A acquires a read lock
2. Process B acquires a read lock
3. A & B both write to the session
4. Process A unties the session, triggering it to acquire a write lock
which blocks on B's read lock
5. Process B unties its session object, triggering it to acquire a write
lock... and voila... deadlock
The really nasty thing is that since the code is not reading the return
value of flock, the deadlock is ignorred and both A and B can write to
the file.
This is pretty nasty and what I have done is segregate the requests by
read and write access. Images, include files, and other support stuff
that don't update the session get a "read only" lock. All other
requests set the Transaction option so they get a write lock right off
the bat.
This solves the deadlock problem, but you still need to handle the other
possible errors from flock.
I have also changed things so that if we got a read-only lock we clear
the modified bit before we untie (but not new or deleted since a session
could be created from an access to a read-only page).
