[mod_python] database connection

Graham Dumpleton grahamd at dscpl.com.au
Sat Oct 15 20:40:53 EDT 2005

A comment on something else in your example first.

> pageAction1 = apache.import_module('pages/action1')

I wouldn't rely rely on being able to specific '/' in the module name as
argument. The documentation only mentions that '.' can be used if
needing to reference a subcomponent of a package. What you are doing is
relying on a strange quirk of the implementation and in mod_python 3.3
if the module loading system is overhauled there may be no guarantee
that it would work the same. You could always campaign though that it
is a useful future that should be maintained but documented. :-)

BTW, does the "pages" directory actually have an "__init__.py" file. I
think what you are doing doesn't require it to, but wanted to check if
you do have it or not.

On 16/10/2005, at 4:28 AM, Julien Cigar wrote:

> Hello,
> I use mod_python for some time now, and I wondered where's the best  
> place to manage database connections / cursors ?
> I run a home made 'publisher' handler and what I'm actually doing is  
> to open a global database connection in the index.py, and pass this  
> variable in classes ... is this the best way ?
> a little example:
> -> index.py:
> import psycopg
> from mod_python import apache
> config = apache.import_module('config')
> connection = psycopg.connect(config.getDbConnectionString())

Some will say that such resource initialisation should be done from a
module imported using PythonImport. The argument is that such  
time consuming operations should be done at child process startup time.
This is really only is valid for Win32 "winnt" MPM. There are also other
problems with that approach, see:


Some of the problems described in that link are pertinent to your case
as well. Ie., because you have done initialisation at module import  
you only get one chance to do it. Thus you should consider only doing it
the first time that a request comes in that requires the resource. That
way you can deal with errors properly. You do though have to contend  
multithreading issues.

Further problems with doing resource initialisation in a request handler
module are that when the module is reloaded where PythonAutoReload is  
the global data will be overwritten meaning your existing connection  
be lost. If it doesn't automatically disconnect properly when disposed
of, it will stay open and each reload will result in another connection
and thus waste of resources and database connections.

In mod_python.publisher in mod_python 3.2 module loading works a bit
differently and data will not be reloaded on top of the existing module
but into a new one. You still result though in the old connection being
lost and if it doesn't disconnect properly, similar problems.

Thus, it is preferable that resource allocation and the storage of the
handle be done in a Python module that is not imported using the module
loading system of mod_python but that "import" be used instead. Such a
module should preferably not be in the document tree but elsewhere on
the Python path. As described in the link above, use an access function
in that module which returns, and creates as necessary, the resource

There is one other idea I have been toying with as to how to store such
resource data to avoid some of these problems, but I'll leave that to
another day. Probably prefer to write that up as a mini article on my
web site. :-)


More information about the Mod_python mailing list