On 12/12/06, David Binger  wrote:
> > One remaining issue is where to put the database connection.  Right
> > now I create it in the controller's .__begin__() method, but that
> > recreates it (and the client socket) for every request.  I may be able
> > to put it in Pylons' 'g' object if it's truly a thread-local global,
> > which I'm verifying.  Otherwise I may make a connection pool and stick
> > it somewhere.  Does the overhead in opening a connection to a Durus
> > server matter that much?
>
> It matters if you care about performance.
> When you don't reuse a connection, you are
> working without any cached objects.  Even if your OS IO buffers
> hold everything in the file, you are, at a minimum, decompressing
> and unpickling every object that you need to prepare the response.
>
> I hope the "g" object solution you suggest works.
> That sounds like a reasonable approach.
> If not, you can make your own thread-local global
> for this purpose.

The Paste people confirmed it won't work.  The 'g' object is local to
a single Pylons application in the process, but shared between all
threads in that application.  (Actually the threads are at the outer
level, akin to Quixote-SCGI's processes.  A thread handles multiple
requests, which could map to one or another WSGI application.  There's
a separate mechanism which switches the 'g' object's value so it
appears local to each application.)

A thread-local would be simplest but a connection pool may be more
"correct" given the indirect relationship of the thread pool to the
application (it goes through several layers of Python packages made by
different parties).  There's also no obvious container in the thread
to store the connection object in.

If I make a connection pool that calls .abort() before giving a
connection to an application, it should avoid the problem of one
request's data leaking into another.

I'm not sure how to return a connection to the pool if the application
just lets it go out of scope rather than returning it.  I'll have to
see how SQLAlchemy does it.
Would a weak reference help?  But where would I put it?  The pool
needs a strong reference to the connection, and the app probably wants
a strong reference too?  Could the pool have a second weak reference
that monitors the application's strong reference?  I'm not sure how to
set that up.

--
Mike Orr