Dieter Maurer schrieb:
That was certainly the case with the date_indexes. We could get rid of
those conflict errors by using the QueueCatalog. But still we are
getting conflict errors on the indexes, we are updating immediatly for
example the review_state.
Joachim Schmitz wrote at 2007-6-16 13:35 +0200:
during our recent search for the cause of the many conflict errors, we
discovered that nearly all of them where caused during indexing the
portal_catalog, when the same values are indexed. This can happen easily
with date_indexes, since the dates are only stored with a resolution of
Usually, this will not cause a conflict -- only when in addition
the first objects that use a new date value are created
in concurrent transactions. I expect that the probability is not
too high for this....
Even more conflict error prone is the reviewstate. Since there
are only a few reviewstates.
Again, only the initial "filling" of the document list for
a given state is critical. Once there is a document list,
this list (an "IITreeSet", usually) can concurrently add elements
(using application specific conflict resolution -- reducing the
conflict probability by a factor of about 120).
I didn't find any application specific conflict resolution in the
fieldindex ? Are you saying, that once there is one document created
within a review_state, conflict errors for that review_state are very
unlikely, even under heavy load.
For one of our internal projects, I have created a set
of "conflict reduced indexes". These indexes do not delete
a document list one it has been created. However, it turned
out that this additional conflict protection is not worth the effort.
My special indexes have been phased out meanwhile....
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests