one very important finding:
tryToResolveConflict fails in the resolve function
resolve built-in method _p_resolveConflict of BTrees._IOBTree.IOBucket
object at 0xb1ab82b4
by raising an exception, when I call it again from the debugger I get.
(Pdb) resolved = resolve(old, committed,
some more findings:
1. The conflict error really happens on the Portalcatalog
2. It is a BTreesConflictError: BTrees conflict error at -1/47/47:
Conflicting inserts which disguised as ConflictError, through the
various try: excepts:
3. It happens on DateIndexes like created and modified.
4.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
some more findings:
1. The conflict error really happens on the Portalcatalog
2. It is a BTreesConflictError: BTrees conflict error at -1/47/47:
Conflicting inserts which disguised as ConflictError, through the
various
Joachim Schmitz schrieb:
I could reproduce the conflict error on my local machine not using ZEO.
I invoked the longrunning process create_level for two users after a
zope-restart.
here is the log:
2007-05-31 09:44:24 INFO Zope Ready to handle requests
2007-05-31 09:44:39 INFO
Hi,
I was able to locate the places in the Zope-sources where the conflict
error is triggered. On my local system it's in
ZODB.FileStorage in the store-method there is
if serial != cached_tid:
rdata = self.tryToResolveConflict(oid, cached_tid,serial, data)
in the tryToResolveConflict
