[Zope] Counter Rentrancy

David Kyte david.kyte@microamps.com
Wed, 28 Mar 2001 16:58:01 +0100


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 )
>