----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Jonathan" <[EMAIL PROTECTED]>
Cc: "Michael Dunstan" <[EMAIL PROTECTED]>; <zope@zope.org>
Sent: Thursday, July 06, 2006 2:56 PM
Subject: Re: [Zope] Trying to trap ConflictError
Jonathan wrote at 2006-7-6 09:53 -0400:
...
From what I understand from the above code, the error is being raised
because the oid already exists and the object pointed to by the old oid is
different from the object pointed to by the new oid, hence the conflict
error.
You interpretation is slightly wrong. What really differs is not
the object (or "oid") but the timestamp.
Each persistent object has a timestamp "_p_serial" which
identifies the transaction that made the last change to the object.
When an object is loaded from the ZODB, its timestamp is
recorded (in "_p_serial"). When later a change to the object
should be commited, the recorded timestamp is compared to the object's
current timestamp in the ZODB. If the timestamps differ, then
the object was modified by a concurrent transaction and our
modification is likely to be based on stale information.
As a result a "ConflictError" is raised.
Thanks Dieter, this got me pointed in the right direction...
The problem was due to multiple processes simultaneously accessing a
'MakeId' routine (as some had suggested earlier in this investigation!).
Even though the routine returned a 10 digit id consisting of a 7 digit
timestamp + 3 random digits, there were still id collisions.
Changing the MakeId routine to return a 10 character string (all 10
characters randomly generated) eliminated the ConflictErrors that were
occurring during heavy load testing.
Thanks to everyone for the great assistance!!!
Jonathan
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
