I am still abit confused about Atomicity. In the counter code if two threads can read the counter value and bump it by one each, then great there is a lock to prevent simultaneous writes back to the property. However both threads are trying to write back N+1 not one writing N+1 and the other N+2. When the code backs off, does it back off and reread the counter? Dave -----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com] Sent: 28 March 2001 17:15 To: Daniel Rusch; David Kyte Cc: zope@zope.org Subject: Re: [Zope] Counter Rentrancy This is a great use for a nonundo ZODB database, especially with the new conflict resolution code in 2.3.1b2+. I'm going to be releasing a "packless" BerkeleyDB-backed nonundo implementation sometime today. I really wish somebody would write a HowTo that explains in generic terms how to use the External Mount product to mount a storage. Randy Kern wrote a great howto that touches on it (http://www.zope.org/Members/randy/ZEO-Sessions), but it's somewhat CoreSessionTracking specific. To answer the question, however, each thread in Zope maintains a single connection to the ZODB. When a commit happens (implied at the end of a request), the connection attempts to modify the database. If another thread is modifying the same object, a ConflictError will be raised and (in Zope) the request will be retried. You needn't worry about locking. You *do* however need to worry about ZODB growth and the hotspot implied by the counter. Though it's ill-documented at the moment, 2.3.1b2+ has app-level conflict resolution code that helps in this case! See http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution. The new class Length in the module Length.py in the BTrees package in 2.3.1b2 is an example of such a counter which makes use of conflict resolution. ----- Original Message ----- From: "Daniel Rusch" <drusch@globalcrossing.com> To: "David Kyte" <david.kyte@microamps.com> Cc: <zope@zope.org> Sent: Wednesday, March 28, 2001 10:02 AM Subject: Re: [Zope] Counter Rentrancy
I could be wrong here, but we did something similar, setting proprieties like this. Although the code is re-entrant what you may see, if you have high enough traffic rates, is that depending on exactly what you are doing you may get Conflicting write exceptions. Additionally, you should be aware that each manage_changeProperties will be logged in your ZODB (look at the undo list) which means that your ZODB will grow. If you have high traffic rates it will grow at an unbelievable rate (ours did). The conflicting write scenario and the writing to the ZODB also means that you will suffer (maybe minor) performance degradation. Are you using a database?
Dan David Kyte wrote:
Hi,
If I have a DTML document for generating and tracking say order numbers, is the code rentrant/Atomic?
<dtml-call "REQUEST.set('counter', counter + 1)"> <dtml-call "manage_changeProperties( counter=REQUEST['counter'] )"> <dtml-return counter >
What I'm really asking is how many threads run in parallel, and how would multiple threads accessing this code react.
Do I need some form of transation or locking?
Thanks in anticipation
David Kyte
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )