us too.
--
Mit freundlichen GrüßenJoachim Schmitz
..
AixtraWare eK ..Joachim Schmitz ..www.aixtraware.de ..t: +49-2464-8851
Hüsgenstr. 33a .d-52457 Aldenhoven .f: +49-2464-905163
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
2007-05
Joachim Schmitz schrieb:
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
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
2007-05-25 09:16:07.870801) (80 conflicts
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:
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
one very important finding:
tryToResolveConflict fails in the resolve function
resolve object at 0xb1ab82b4>
by raising an exception, when I call it again from the debugger I get.
(Pdb) resolved = resolve(old, committed, newstate)
*** BTreesConflictError: BTrees conflict error at -1/47/47: Co
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 buck
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".
Tres Seaver schrieb:
{'Application': , 'ZGlobals': object at 0xb2739224>}
What does this tell us ?
That is a "real" conflict: both transactions have inserted values into
the 'created' date index's '_index' under the same key, which can't be
resolved. Retrying the transaction is the
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 j
hi,
we use ZCatalogs as tables, to store data for rapid access and
searching. Recently we added a keyword index to one table, and found
that the metadata of the index is not updated, when a keyword is
added.The name of the index and metadata is the same
"registered_courses". I found in Catalo
12 matches
Mail list logo
