> On 11/07/2011 03:15 PM, Darryl Dixon - Winterhouse Consulting wrote:
>> Hi All,
>> We have just converted a site with a handful of editors over from ZEO to
>> RelStorage on Oracle and and the rate of ConflictErrors has gone through
>> the roof (5 an hour average continuously for days).
>> Currently we are using a very basic
>> RelStorage configuration without any additional bits like memcache.
> I have a few thoughts:
> - You aren't using poll-interval, are you? Make sure that is disabled.
> - When you switched from ZEO to Oracle without turning on memcache, you
> lost the ZEO cache and didn't replace it with anything, so now loading
> objects takes longer, which may lead to more conflicts. I would try
> turning on memcache.
> - Do you have multiple storages / databases? Make sure each uses a
> different Oracle lock ID.
We are not using the poll-interval, so clear on that one. I wasn't clear
that memcache would assist in this situation - I will see about enabling
it in this environment, but there are a few questions I need a better
understanding for with this around what exactly are the characteristics of
* What is the situation with using multiple memcache instances (eg, one
per machine - will this lead to cache incoherency - inconsistency between
* What is the failure scenario for a memcache instance dying - is it
handled gracefully by RelStorage or will there be
hanging/blocking/tracebacks until it returns?
* Will this potentially exacerbate the ancient ZEO-Client-Race condition
that occurs with load-balancing when data changes? (To be clear, I am
referring to when one Zope instance updates/commits some data, and then
the client browser makes a new request which is directed to a second Zope
instance, which has not yet received an invalidation message for the
changed objects, and it returns, eg, a 404 to the client).
Any guidance on the above once again very gratefully received.
With regards the the commit lock - yes, we use multiple storages and each
uses a different commit-lock-id.
Thanks heaps for your help,
Winterhouse Consulting Ltd
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org