James Y Knight wrote: > >> 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. > > Okay, so I think the overall recommendation from DB-SIG is "don't do > that". I'm not sure where that leaves the WSGI discussion > now? "Don't > use databases from a result iterator", I guess (unless threadsafety > == 3)? But do anybody else's WSGI server implementations move apps > between threads? I don't especially want to make Twisted's be unique > in this way even if it is technically allowed, as I can only see it > causing problems when people's apps *do* try to use databases from > result iterators and *do* work everywhere else...
I have to admit that none of the apps, servers, or gateways I've worked on have allowed for thread-moving or -sharing. I'm pretty well convinced that CherryPy, for example, won't be able to support that anytime soon--thread isolation is too well baked in. Couldn't someone write a piece of WSGI middleware that takes requests from an async server and dispatches them to a pool of Queues? The consumer side of the Queue would then call the WSGI app with the same thread each time for a given request, but the async-server side would be free to create new requests and fetch results from different threads. Sort of an async-to-threaded bridge. I would think, even if you chose not to build that into your WSGI wrapper, that it would be generic enough to be quite useful for any async server + threaded app. I'll refrain from any predictions about performance, however... ;) Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
