On Mar 11, 2011, at 5:13 AM, Massimo Di Pierro wrote: > > This is a strange behavior of open. Which linux version? Anyway, I > will test your solution, it seems the right one.
No. The second open unlocks the file (presumably because f is closed with f gets rebound) and it's not getting locked again. > > Massimo > > On Mar 11, 3:30 am, Corne <[email protected]> wrote: >> Hello, >> >> We were running into the following: >> >> (os: Linux - Apache with mod_wsgi) >> >> We have client code which does a number of requests: >> what happened is that some of these requests got 401-not authorized as >> response. >> >> The problem is that in globals.py the session file is opened (rb+) and >> the file is locked. >> The second request (which is handled at the same time from a different >> process) tries to do the same; but the file is still locked at that >> time. >> Expected result would be that we have to wait for the lock to free, >> but instead open throws an exception. >> >> As solution we now first open the file for reading, than acquire the >> lock; and finally open the file for reading/appending (rb+) >> >> Opening the file for reading will succeed, than the lock is acquired >> (or we wait until we can get the lock). When we have the lock there is >> no problem opening the file for reading and writing anymore.. >> >> Patch: >> --- globals.py 2011-03-11 10:13:22.634740461 +0100 >> +++ globals.py_new 2011-03-10 15:43:55.000000000 +0100 >> @@ -270,9 +270,11 @@ >> if response.session_id: >> try: >> response.session_file = \ >> - open(response.session_filename, 'rb+') >> + open(response.session_filename, 'r') >> portalocker.lock(response.session_file, >> portalocker.LOCK_EX) >> + response.session_file = \ >> + open(response.session_filename, 'rb+') >> self.update(cPickle.load(response.session_file)) >> response.session_file.seek(0) >> oc = response.session_filename.split('/') >> [-1].split('-')[0]
