On 5/31/07, Joachim Schmitz [EMAIL PROTECTED] wrote:
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,
Joachim Schmitz wrote at 2007-6-1 20:26 +0200:
A longer term solution might be to come up with a derived index type
which used non-persistent objects (rather than the IITreeSet used by
UnIndex) for the set of RIDs stored under each 'minute': you could then
inspect the state and do more
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,
Tres Seaver schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not if the sessions being used are from 'faster' -- it doesn't use
IOBTree. The major application use of that module is in the catalog.
you correct see below:
Try dumping out the contents of the bucket:
for k, v in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Tres Seaver schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not if the sessions being used are from 'faster' -- it doesn't use
IOBTree. The major application use of that module is in the catalog.
you correct see
Tres Seaver schrieb:
BTrees._IOBTree.IOBTree object at 0xb562fadc
DateIndex at created
Products.ZCatalog.Catalog.Catalog object at 0xb12d622c
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Tres Seaver schrieb:
BTrees._IOBTree.IOBTree object at 0xb562fadc
DateIndex at created
Products.ZCatalog.Catalog.Catalog object at 0xb12d622c
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
Any suggestion for a temporary fix would be very welcome, since we get
about 6000 conflict errors per day now about 15 % unresolved, and they
are really killing our portal.
A workaround might be to replace the DateIndexes for 'created' and
'modified' with FieldIndexes: you will see a big
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Any suggestion for a temporary fix would be very welcome, since we get
about 6000 conflict errors per day now about 15 % unresolved, and they
are really killing our portal.
A workaround might be to replace the DateIndexes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jürgen Kartnaller wrote:
We also run into this kind of problems.
The only save way to solve it was to serialize our index updates.
We do this by using one zope instance which runs only a
lovely.remotetask task service. This service contains
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jürgen Kartnaller wrote:
We also run into this kind of problems.
The only save way to solve it was to serialize our index updates.
We do this by using one zope instance which runs only a
lovely.remotetask task service. This
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
I deleted the created objects and repeated the test:
2007-05-31 12:46:12 ERROR Zope.ZCatalog uncatalogObject unsuccessfully
attempted to uncatalog an object with a uid of
/uniben/campus/students/A923157/study_course/200/ZOO213.
2007-05-31 12:47:05 INFO Skins.create_level Y617041 started to
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
resolve bound method Length._p_resolveConflict of BTrees.Length.Length
object at 0xb28fff6c
resolve built-in method _p_resolveConflict of BTrees._OIBTree.OIBucket
object at 0xb1b81224
resolve built-in method _p_resolveConflict of BTrees._OIBTree.OIBucket
object at 0xb1b81224
resolve
Hi Dieter,
thanks for this hint.
Dieter Maurer schrieb:
Perry wrote at 2007-5-25 13:16 +0200:
database conflict error (oid 0x7905e6, class BTrees._IOBTree.IOBucket,
serial this txn started with 0x036ddc2a44454dee 2007-05-25
09:14:16.000950, serial currently committed 0x036ddc2c21950377
17 matches
Mail list logo
