zodb troubles - seeking advice for app design

[Dieter Maurer]

"Diez B. Roggisch" <deetsNOSPAM at web.de> writes on Thu, 06 May 2004 14:16:10 +0200:
> the docs on zodb are spare, so I try my luck in this ng.

You did not look well enough!

There is the "zodb3.pdf" document and a "ZODB guide" (maybe "ZODB
tutorial"). At lease they cover your essential question...

> ...
> Everything works fine - in a single threaded app. But under load, the
> omniorb will dispatch the incoming calls on several worker threads. zodb
> requires that for each thread a separate connection has to be used. I'm not
> sure how bad sharing the connection would be, but can imagine that this
> isn't the best idea....

It is very bad!

The ZODB does not provide a locking facility.
It would need to if several threads could change concurrently
the same data. This would drastically complicate ZODB usage.

Instead, the ZODB gives each connection its own (partial) copy
of the ZODB content. Threads work on this copy only.
The ZODB expects that no two threads access the same connection
at the same time. If this condition is meet, then different threads never
modify the same data.

Of course, different threads can modify different copies of
the same ZODB object. However, the ZODB will recognize such
a fact during the (second) commit and raise a ConflictError
in this case.

As you see, different threads *MUST NOT* use the same connection.
Open a new connection for each thread (and close it before
the thread dies).


Dieter