[mod_python] database connection

Graham Dumpleton wrote:

> 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.
>
My directory structure looks like this :
index.py
config.cfg
config.py
pages/page1.py
pages/page2.py
pages/page3.py
...

My "pages" directory doesn't contain an __init__.py file (should I ?)
I don't understand what's wrong with 
apache.import_module(pages/page1.py) .. ? I always done like this :)
Is it specific to mod_python ? I mean can you import pages/page1.py with 
the classic Pyhon import ?

> 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  
> potentially
> 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:
>
>    http://www.modpython.org/pipermail/mod_python/2005-September/ 
> 019092.html
>
> Some of the problems described in that link are pertinent to your case
> as well. Ie., because you have done initialisation at module import  
> time,
> 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  
> with
> multithreading issues.
>
> Further problems with doing resource initialisation in a request handler
> module are that when the module is reloaded where PythonAutoReload is  
> on,
> the global data will be overwritten meaning your existing connection  
> will
> 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.
>
Right ... I haven't thought at this

> 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
> handle.
>
ok I'll try this.. I haven't yet played with apache.register_cleanup(), 
that will be the occasion to do it :)

> 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. :-)
>
great :)
Thanks for support !

> Graham
>