[ZODB-Dev] RelStorage: Clearing temp_store in replication-friendly way

[Shane Hathaway]

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.

> [1] http://svn.zope.org/relstorage/branches/1.1/?rev=88789&view=rev
> [2] http://svn.zope.org/relstorage/branches/1.1/?rev=88790&view=rev
> 
> 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.

Shane