[mod_python] Persist database conn, or pers. variables - where I put them ?

Fredrik Sandin wrote ..
> 
> I asked the same question some time ago:
> http://modpython.org/pipermail/mod_python/2006-August/021924.html
> Graham Dumpleton suggested to use XML-RPC.
> 
> As far as I have understood mod_python, or actually Apache, was
> not designed to allow for object persistency.
> 
> Cheers,
> Fredrik
> 
> 
> On Wed, 27 Sep 2006 14:20:24 +0200, durumdara <durumdara at gmail.com> wrote:
> 
> > Hi !
> >
> > I not fully understand that in this dynamic wwwserver context where I
> > can put persist objects.
> > What I can do to keep my objects in the background ?
> > Anybody can help me ?
> >
> > Thanks for it:
> > dd

For the record, the question which prompted the suggestion of looking at XML-
RPC was not the same so one can't draw any parallels. In that prior case it was
communication between a GUI front end and mod_python as a back end. In this
case it is communication between mod_python and a database backend. In this
case the true persistent data is in the database and what is really being
talked about is the ability to reuse client side database handles in
mod_python. Thus, the persistence being talked about is on objects relate to
the controller mediating access to the data and not the model or data itself.
As others have pointed out, the need to persist these client side database
handles is actually optional. In the old example, there was a desire to persist
the data of the model in mod_python itself, which is totally different issue.

Having said all that, one should read:

  http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel

This explains a bit about the ability to persist data in the mod_python world.

One issue not discussed there though is the issues that can arise when data is
held in modules which can be reloaded by mod_python. This is covered a bit in:

  http://www.dscpl.com.au/wiki/ModPython/Articles/ModuleImportingIsBroken

Especially issues 9, 12, 13, 17, 19 and possibly others.

Because of the way the module importer changes between versions 3.1, 3.2 and
3.3 of mod_python, about the only totally reliably way of ensuring data is
persisted in only one spot and not lost or corrupted due to module reloading in
some way, is to create a module instance explicitly, stash it in sys.modules
under a pseudo name and store your data in their. Doing that helps to avoid
reloading problems or needing to contend with mod_python 3.3 specific means of
migrating data between module instances when reloaded. I can give an example
of this later if need be, but for what you are doing with database connections
don't think you need to persist them until you have shown that creating them
each time is a problem.

Finally, you need to be careful with doing work at global scope in a module which
might result in an exception occurring, like creating persisting database connections.
This is because a failure will cause the loading of the module to fail which can
cause problems on subsequent reloads or in worst cases require Apache to be
restarted. For one example of this in relation to the PythonImport directive, see
notes associated with:

  http://issues.apache.org/jira/browse/MODPYTHON-118

If you really want to create persisting database connections, do it in a function
which acts like a singleton returning the object. Ie., it would only create the object
if it doesn't exist. The function would be called every time you need the object
and thus it would only be created first time you need it. If using mod_python 3.3
you might use ability of PythonImport to call a function if you really want it done
on child process initialisation before any requests handled.

Graham