On 11/10/2011 05:32 PM, Darryl Dixon - Winterhouse Consulting wrote:
> * What is the situation with using multiple memcache instances (eg, one
> per machine - will this lead to cache incoherency - inconsistency between
> instances, etc?
One memcache per client? That's fine as long as you don't set poll-interval.
> * 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?
That is a function of the memcache client module that you choose. The
default choice is pylibmc_wrapper, a module in the relstorage package,
which handles most memcache errors. I have not seen it hang, but
anything that uses TCP introduces the possibility of hanging. You can
easily make your own pylibmc wrapper module.
> * 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).
That can happen if you set poll-interval to a nonzero value and you
don't share memcache between instances. It can also happen if you misuse
the read-only replica support that's coming in the next version.
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org