Stefan H. Holek wrote:
I have made two checkins to relstorage 1.1 branch:

It's really cool to have another contributor. Thanks! 1.1c1 has already been tagged, so I fixed the change log.


If someone wants to discuss them this is the thread. ;-)

Ad [1]:
This clearly is not the only problem with temporary tables and replication. What the change does, however, is turn a hard error - which stops replication in a way requiring operator intervention - into a recoverable failure. And all this in an application neutral way! <Applause here>

We hope to tackle the main issue (a.k.a. better-not-use-temporary- tables-with-mysql-replication-at-all) in a later installment.

Ok. Conceptually, what we need is a way for each connection to write to a scratch table that no other connection can see. Is there a better way to do that than temporary tables?

P.S.: I am quite excited about the memcached support. Does it "just work"? I.e. can I run my ZODB in RAM now? ;-)

I expect the new memcache support to be safe for everyone to use, but we still require the main database to be connected at all times, since memcache provides no ACID properties by itself. We unfortunately can't do obvious things like cache the current transaction ID for an object, since that would break MVCC. What we do cache is:

1. The current tid, given an oid and the transaction ID that is active for the current connection.

2. The pickle given an oid and tid.

These should both help read-heavy databases, but might be detrimental for write-heavy databases. My performance test suite, which writes a lot, produced slightly *worse* results with memcache enabled.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to