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

Sorry, I misread your message.  What you're describing is the way
MySQLdb works, as well as all thread-friendly database systems I've
seen.  Perhaps ACKS.txt should be changed so it doesn't scare people
off:

"Unlike ZODB/ZEO, Durus does not support multi-threaded database
access"

--
Mike Orr  or