http://code.google.com/p/spinn3r-client/wiki/ClientDesignGuidelines

We have clients pounding us with requests (about 10M request per client per month) and a non-trivial amount of bandwidth…..(hundreds of GBs per month).

We wrote up the common mistakes we found with API implementations.

… might help and interesting in the least.

Yes I know about session_write_close() however it is a code change which is different angle of tuning and in this case information is stored in the section after web server call returns.

Session files are locked on purpose and I’m not sure how memcache is not locking. This is just what I’ve seen in practice. I guess in memcache you would just have race condition and it is possible with concurrent requests being executed second request to overwrite first request data. If this is the case it is something surely to watch out when you write apps.

I honestly would prefer explicit locking to implicit one – if application suffers from race conditions let it synchronize to avoid them. MySQL users often have so much race conditions in their apps they do not care about anyway

To release the lock in the middle of a script use session_write_close()