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 > >
|