On 12/19/05, M.-A. Lemburg <[EMAIL PROTECTED]> 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/) _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
