[mod_python] For what session locking is? Do i need it while using MySQL?

Jim Gallacher jpg at jgassociates.ca
Fri Aug 11 12:17:50 EDT 2006


Norman Tindall wrote:
> Hello Jim,
> 
>       Yesterday i realized what i saw in BaseSession class and i
>       think it is terrible.
> 
> def lock(self):
>      if self._lock:
>          _apache._global_lock(self._req.server, self._sid)
>          self._locked = 1
>          self._req.register_cleanup(unlock_session_cleanup, self)
> 
>   Attention to last line of fuction "self._req.register_cleanup(unlock_session_cleanup, self)"
>   so the unlock of session happens when last byte of a request sent to
>   client and reqest object is to be destroyed.
> 
>   And what if i write in handler something like this:
> 
>   for x in range(100):
>        time.sleep(1)
>        req.write(str(x) +" "+ str(sess._locked)  + "<BR>",1)
> 
>   Session will be locked for a 100 seconds!
>   Well there may be a blocking timeout but i don`n know how
>   How parallel thread handle this situation with 100 sec session
>   blocking.
> 
>   I think it SHOULD be added to documentation that after all
>   manipulation with session data is made you MUST unlock it
>   explicit.
> 
>   For example in my handler i can unlock even before headers is sent
>   to client - and it is much more faster than 100 sec.
> 

On the contrary, BaseSession.lock() does *exactly* the right thing. The
giveaway is the fact that it is registering a *cleanup*. The point of
the cleanup is to make sure the session is unlocked. Without that a
small coding error, such as forgetting to unlock the session, would very
quickly deadlock the server as the mutexes used for locking are a
limited system resource. The cleanup code makes sure the application
writer does  not shoot themselves in the foot, and take down their
server at the same time.

lock() and unlock() are public methods and the app developer is free to
call them anytime they want. Not every use case can be anticipated it
would be wrong to dictate when session unlocking should occur, beyond
ensuring that it *does* occur. It's the app developer's responsibility
to understand their own code, and adjust accordingly. Personally I think
that for the majority of cases using implicit unlocking in the request
cleanup works just fine. Are there times when I would explicitly unlock
a session? Absolutely, but I'm happy that I don't normally need to worry
about it.

Jim





More information about the Mod_python mailing list