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 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. 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. 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. :-) Graham
|