m.banaouas
banaouas.medialog at wanadoo.fr
Wed Dec 27 06:01:58 EST 2006
I looked at http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel and of course found it very interesting, expecially for interpretter and process. I must precise that my curent devloppement is under XP. So I'm concerned with winnt mode. In any mode, we must do special stuff to make database connexion variable survive between requests. If we avoid global variable as suggested by the article, shared memory seems to be the best solution, because database storage for database connexion variable makes no sense ... Must I make moore interest about "shared memory" solutions like POSH (Python Object Sharing) or is there common module in python ? Graham Dumpleton a écrit : > > On 27/12/2006, at 8:20 PM, m.banaouas wrote: > >> The fixup handler is probably the more elegant way to handle database >> connexion >> I suppose that this connexion (or pool of such objects) will "survive" >> (kept alive) between successive requests? > > Provided it is stored in a global module variable somewhere and suitable > protection is implemented so as deal with module reloading if appropriate. > >> you suggest to cache them in the request object: do you mean like its >> usually done with session id, added to all successif url or in hidden >> field? or should I add their reference in the request object during >> fixup handler execution time? > > The reference is added to the request object merely as a convenience so > the actual response handler doesn't itself have to go work out where to > get the database connection handle from. Thus: > > def fixuphandler(req): > # check if database connection initialised and if not initialise it > > # cache a handle to database connection object in request object > # so response handler can use it > req.database = ... > > return apache.OK > > Then later: > > def handler(req): > database = req.database > > # do stuff with database > > return apache.OK > > In other words, it localises a lot of the database imports potentially > to one place and you don't end up having it spread through all your > handlers as well. > >> from PythonHandler family, PythonInitHandler seems to be an other one appropriate for this job, is it ? > > PythonInitHandler is broken and doesn't work as advertised. See: > > http://issues.apache.org/jira/browse/MODPYTHON-209 > >> To avoid to me any mis-understanding, the long-live connexion object will reside as a global module variable ? may be that why "interpretter" is usually montionned in PythonImport" threads: the globals will survive because the python process is the same one and is never stoped by apache? > > Interpreter name has to be specified with PythonImport as at point that > that directive is processed is outside of any request so not possible to > automatically determine what interpreter instance to perform the import > for. Obviously you have to ensure it is the same as what any request > handlers use. By default it would need to be virtual host name, but could be > something else if using PythonInterpreter directive. > > I might suggest though that you read: > > http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel > > as your terminology suggest you might not quite understand the > relationship between process and interpreter instances. > > Graham > >> Graham Dumpleton a écrit : >>> To avoid having to do it in lots of different places, for example if using >>> mod_python.publisher, you can define a fixup handler which does it >>> for you. The one fixup handler will be invoked for every request in that >>> context. You could even cache a reference to the database connection >>> handle in the request object ready for the subsequent response handler >>> to use it. >>> >>> Graham
|