CGI: keeping mySQL awake between hits?

[Miles Clark]

Have a look at FastCGI (http://www.fastcgi.com).  It has a similar API
to CGI, but creates a persistent process that allows you to cache DB
connections, etc.

Here's a *very* simple example of a python FastCGI script that accesses
a PostgreSQL database.  Note that the db connection is not recreated for
every hit (all hits are handled in the while loop):

-------------------------------------------------------------

#!/usr/bin/python
#-*- mode: Python; tab-width: 4;-*-
import traceback
import sys
from time import *

try:
        
        import pg
        import fcgi

        conn = pg.DB(dbname='foodb', user='foouser')

        while fcgi.isFCGI():
                req = fcgi.FCGI()

                print "Content-type: text/html\n"
                print "<pre>"

                if not conn:
                        print 'bad connection<p>'
                try:
                        output = conn.query("select * from test")
                        print `output.getresult()`
                except:
                        traceback.print_exc(file=sys.stdout)

                print "</pre>"

                req.Finish()

except:
        traceback.print_exc(file=sys.stdout)
 
------------------------------------------------------------------

jhefferon at my-deja.com wrote:
> 
> I have CGI scripts that want to write to a database.  If I have that
> every hit causes Python to wake up, and then mySQL to wake up, so that
> the script can write to the database (and then they both go back to
> sleep) then the response is very slow.
> 
> I understand that I can put Python into Apache as a module, so that
> Python will always be awake.  I want to also keep mySQL up (maybe
> a half-dozen clients).  I believe that I can do this with Perl's
> Apache::DBI, but I'd much to prefer to go with Python.
> 
> Can I?  (I thought that this is a Python issue because Python needs
> to talk to the open connections -- isn't that why Apache::DBI is a
> Perl module?  I looked a bit in the SIG database archives and did a
> few deja queries but I didn't see any discussion of this; sorry if I
> missed a recent one.)
> 
> Thanks,  Jim jim at joshua.smcvt.edu
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.