[mod_python] Session Hanging Problems

On 05/12/2007, Jim Gallacher <jpg at jgassociates.ca> wrote:
> Harish Agarwal wrote:
> > Have you noticed any performance issues?  I want to make sure to keep
> > things fast and am worried that departing from the Apache lock system
> > will degrade performance.  Why was mod python designed to use the apache
> > system and not use session specific locks?
>
> I wasn't around when session handling was first introduced, but I assume
> the apache mutexes where used so that mod_python would be as
> cross-platform as possible. Python's fcntl.flock() is only available on
> *nix platforms.

Important thing to note is that the session locks must be cross
process on UNIX. Part of the problem is then that certain types of
lock mechanisms may not be able to be used by arbitrary processes.
Instead, a parent process needs to initialise the lock. That lock must
then be inherited through a process fork, with some reinitialisation
done in the child to cope with process owner changes, and then used.
Typically, the most efficient sorts of cross process locks work this
way.

Because no mod_python specific Python code is run within Apache parent
process, there is no opportunity for such style of locks to be setup
from Python code, so the APR C interfaces are used to do it and then
those interfaces exposed through to Python code.

In some respects it is a bad design as it means that Session code is
tightly bound to Apache. If it wasn't done this way then feasibly one
could more or less port the Python frameworkish code to work on a
different web server infrastructure.

BTW, the portability argument isn't necessarily valid as on Windows,
the only other platform mod_python really runs on, you can use Python
in process locks as session locks. This is because you don't have
multiple processes and so don't need cross process locks.

> The big drawback with apache's mutexes is that we are dealing with
> limited resource.

Only the case for certain types of cross process locks, eg., sysvsem.

Graham