[mod_python] ValueError: Failed to acquire global mutex lock

Julian Ciccale jciccale at mac.com
Mon Nov 24 02:49:40 EST 2003


Kind of. What I do is the followoing

try:
    from mod_python.Session import Session as DefaultSessionCall
except:
    def DefaultSessionCall( r ):
       return None

, this is a peice of code I use to make configurable the Session class the user wants to use. I also then try to call a setter method on a user's class to pass the session he works on. How should I use the session? The locking mechanism is needed for read/write or just write? I think I may write a session wrapper class to lock unlock on user call to get/set properties..


 
On Monday, November 24, 2003, at 02:15AM, Gregory (Grisha) Trubetskoy <grisha at modpython.org> wrote:

>
>
>On Sun, 23 Nov 2003, Julian Ciccale wrote:
>
>> Hi and thanks,
>
>>   I got that problem solved but now it seems it's happening something
>> weird. I compiled the sources from CVS (enabling the debugging lines on
>> the locking calls). On a first request i get these lines:
>>
>> [Sun Nov 23 12:17:51 2003] [warn] _global_lock at index 30 from pid 21429
>> [Sun Nov 23 12:17:51 2003] [warn] _global_lock DONE at index 30 from pid 21429
>>
>> , which seems to lock mutex at ix 30. (and remains locked even when the
>> request has completed). Then when a second request comes i get this:
>>
>> [Sun Nov 23 12:18:02 2003] [warn] _global_lock at index 30 from pid 21425
>>
>> . Obviously that process remains locked forever, waiting on a lock forever.
>
>How are you using your sessions? Do you by any chance assign it to a
>global variable - the session releases the lock when you call it's ulock()
>method explicitely, or when it goes out of scope, so assigning it to a
>global would make it stay there and locked even after the request is done.
>
>Grisha
>
>


More information about the Mod_python mailing list