Multithread ZODB.

David Bolen db3l at
Thu Feb 22 21:06:28 EST 2001

amk at (A.M. Kuchling) writes:

> On 20 Feb 2001 18:09:15 -0500, Cary O'Brien <cobrien at Radix.Net> wrote:
> >Isn't ZODB thread safe?  I mean Zope runs as multiple threads, doesn't
> >it?
> Yes it does, but I have no clear idea what the ground rules are for
> doing that, and so can't really document them.

It's actually more than thread-safe, it's designed to have the object
store run via multiple threads, and each thread sees its own copy of
the objects independently.

That way, if you have two users working on the web site simultaneous,
within a transaction, each sees an internally consistent view of the
object store, without being impacted by any changes from the other
user with that other transaction.  If the first user commits changes,
the second user will then see those changes in his/her reference to
the objects from the local connection - and receive a conflict error
if trying to commit changes to the same objects now changed.

If I read it correctly, the original question in this thread is
actually asking about a simpler scenario - where the application is
multi-threaded, but access to the object store need not be, and in
fact is preferred not to be.  That's what our application also wanted
- the object store represented a single state that was managed by a
multi-threaded application, but the application had it's own locking
and management of access to the data - it didn't represent independent

>From my understanding, it's like ZODB solved the much harder problem,
but in doing so it made some assumptions (like per-thread connections)
that actually makes the application approach (not multi-user) more
difficult :-)

-- David
 \               David Bolen            \   E-mail: db3l at  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \

More information about the Python-list mailing list