On Oct 25, 2005, at 9:16 PM, Mike Orr wrote:

> On 10/25/05, David Binger  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.