Dieter Maurer schrieb:
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 1 minute.

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....

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.

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....


Gruß Joachim

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to