Yo, I read on the doc's : """ A key feature of Zope 2 (ZODB 3) is that (a copy of) a persistent object is never accessed by more than one thread (unless the programmer goes way out of thier way). Each thread uses it's own database connection(s). Each connection has it's own copies of persistent objects. This feature provides a major simplification for application developers. """ This explains the problems we have with our system: we have a multithreaded system where each thread iteratese over a set of objects in the ZODB, and sees of something needs to be done... if so the thread does it. Now since each thread gets its own version of the object. our actions occur multiple times... This is not the desired behaviour. Is there a way we can share the access to the objects, or do we have to create a global lock ? And if we have to create a global lock, what's the desired/standard approach in doing so. TIA, Sloot.
Romain Slootmaekers writes:
Is there a way we can share the access to the objects, or do we have to create a global lock ? And if we have to create a global lock, what's the desired/standard approach in doing so. You may have a look at "SharedResource" at
On Sun, 10 Mar 2002 11:52:24 +0100 (CET), Romain Slootmaekers <romain@zzict.com> wrote:
This explains the problems we have with our system: we have a multithreaded system where each thread iteratese over a set of objects in the ZODB, and sees of something needs to be done... if so the thread does it. Now since each thread gets its own version of the object. our actions occur multiple times...
I suggest one thread that scans the database. when it finds some work to be done it adds a specification of the work into a work queue. Seperate worker threads get thier work specification from the queue. Exactly how you store the work queue depends on other factors, but I suggest not in ZODB. Toby Dickenson tdickenson@geminidataloggers.com
participants (3)
-
Dieter Maurer -
Romain Slootmaekers -
Toby Dickenson