[Web-SIG] WSGI thread affinity/interleaving

[James Y Knight]

On Dec 17, 2005, at 5:25 PM, Phillip J. Eby wrote:
> Yeah, that was the thing, I don't think we wanted to guarantee  
> thread affinity across yields, either in the sense of restricting a  
> thread for one app *or* an app to one thread.
>
> This does mean that iterator-based apps can't rely on thread-local  
> variables.  I've recently written a "Contextual" library that  
> actually makes it easy for the task controller to manage this, by  
> swapping a thread's context in and out when you switch between  
> tasks, but of course it won't work for anything that doesn't use  
> Contextual variables.  I originally proposed Contextual for the  
> stdlib in a pre-PEP, but Guido waved it off on the basis that PEPs  
> 342 and 343 aren't field-deployed yet and the usefulness is  
> unproven.  WSGI, however, would be an example of a case where  
> contextual task-locals are needed even with today's Python, sans  
> PEPs 342 and 343.

I'm worried about database access. Most DBAPI adapters have  
threadsafety level 2: "Threads may share the module and  
connections.". So with those, at least, it should be fine to move a  
connection between threads, since "share OK" implies "move OK".  
However, no documentation I've found has said anything separately  
about whether it's safe to _move_ a cursor between threads. It seems  
likely to me that it would not be safe, at least in some database  
adapters. And if it's not safe, that means a WSGI result iterator  
cannot use any DBAPI cursor functionality which seems a drag.

Does anybody have practical experience with the safety of moving a  
DBAPI cursor between threads?

James