[mod_python] Persistent db connections

Mike Looijmans mike.looijmans at asml.com
Fri Aug 8 07:25:15 EST 2003

More importantly, make sure that your DB engine supports multiple threads
over a single connection.

If you're using a threading MPM, there will be multiple clients sharing the
same connection.

For MySQL for example this will fail if you also use scrolling cursors,
since you can have only one such cursor per connection.

What I did was to use a threading-only MPM and have each request grab a DB
connection from a pool (and remove it), and when done, it returns the DB
object to the pool. If the pool is empty, a new connection object is created
(so the pool grows automatically to meet demand).
This allows many threads to use the same connection objects, but no threads
will ever share the same object.

If the number of connections is limited, you could create a fixed number of
objects and do a lock-and-wait until one is available when the pool is


-----Original Message-----
From: VanL <vlindberg at verio.net>
To: Conrad Steenberg <conrad at hep.caltech.edu>
Cc: ModPython mail list <mod_python at modpython.org>
Date: Thursday, August 07, 2003 7:22 PM
Subject: Re: [mod_python] Persistent db connections

>Conrad Steenberg wrote:
>>Using dbpool would make your web app fail more gracefully, i.e. get
>>slower with more connections, instead of giving some users an error that
>>it was unable to connect to the DB, as you often see on overloaded
>>discussion sites.
>Is this correct?  I thought that even dbpool would not pool resources
>between different apache processes.  Thus having a
>one-connection-per-process (or two, or three, but some fixed number)
>rule along with an apache maxclients setting would tend to keep the
>database connections within an acceptable range.
>If the max number of clients could be known, regardless of the number of
>apache child processes, that would be great.  However, that doesn't
>match my understanding of how it works.

More information about the Mod_python mailing list