On Oct 25, 2005, at 9:16 PM, Mike Orr wrote:
On 10/25/05, David Binger <[EMAIL PROTECTED]> wrote:
On Oct 25, 2005, at 6:01 PM, Mike Orr wrote:
Durus is held back by its thread unsafety. I'm not using threads
now
but I don't want to lock myself out of a multithreaded WSGI server
later, for instance. And multithreaded servers are the most common.
Yet I also don't want to convert my data and code from Durus to ZODB
when the time comes for threads, especially since the need may arise
with short notice. (A compelling server or library; a need to serve
the application on Windows, etc). That makes me think long and hard
about using Durus, even if I don't need ZODB's extra features.
I think that a Durus client process can be multi-threaded as long
as no Connection instance is used by more than one thread.
But that's precisely what you'd need if every request accesses the
database, and requests are running concurrently in threads.
If you have n threads, you can use n Connections, one in
each thread. I think this may be the expectation in ZODB applications
as well.
In processing a request, you must have, I think, a transactionally
consistent view of the database, and that is just what the Connection
provides, as long as no other thread is using it.
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
