[DB-SIG] [Web-SIG] WSGI thread affinity/interleaving

Guido van Rossum guido at python.org
Sat Dec 31 06:10:02 CET 2005

On 12/19/05, M.-A. Lemburg <mal at egenix.com> wrote:
> Ok. In that sense, I think "moving" is not really possible
> with database connections or cursors: these always rely on
> external resources and these may be relying on having the
> same thread context around when being called.
> Why would you want to "move" cursors or connections around ?

A typical connection (or cursor) caching implementation used from a
multi-threaded program might easily do this: a resource is created in
one thread, used for a while, then given back to the cache; when
another thread requests a resource, it gets one from the cache that
might have been used previously in a different thread. Keeping a cache
per thread is a bit cumbersome and reduces the efficacy of the cache
(if a thread goes away all the resources cached on its behalf must be
closed instead of being made available to other threads).

I'm not sure I understand what resources a typical DB client library
might have that are associated with a thread instead of with a
connection or cursor -- IOW I don't understand why you think moving
resources between threads would be a problem, as long as only one
thread "owns" them at any time. IOW if I maintain my own locking, why
would I still be limited in sharing connections/cursors between
threads? What am I missing?

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the DB-SIG mailing list