On 12 October 2011 23:53, Shane Hathaway <sh...@hathawaymix.org> wrote:
> As I see it, a cache of this type can take 2 basic approaches: it can
> either store {oid: (state, tid)}, or it can store {(oid, tid): (state,
> last_tid)}. The former approach is much simpler, but since memcache has
> no transaction guarantees whatsoever, it would lead to consistency
> errors. The latter approach makes it possible to avoid all consistency
> errors even with memcache, but it requires interesting algorithms to
> make efficient use of the cache. I chose the latter.

On first reading I had thought that the {oid: (state, tid)} approach
would not necessarily lead to consistency errors as a connection could
simply discard cached values where the cached state tid is later than
the current transaction's last tid. But I guess that it must be
impossible for a committing connection to guarantee that all cached
oids remain invalidated during a commit and are not refilled with a
previous state by another connection performing a read. This would
necessitate the same checkpointing algorithm to avoid consistency

I sometimes wonder if it would be better to separate the maintenance
of the oid_tid mapping from the storage of object states. A database
storing only the oid_tid mapping and enough previous tids to support
current transactions -- essentially the Data.fs.index -- would always
fit easily in RAM and could conceivably be replicated to every machine
in a cluster to ensure fast lookups. The storage / caching of object
states could then be very simple.

For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to