When using a database server (ZEO, relstorage), you can make a configuration error that causes you to connect to the wrong database. This can be especially painful in a situation where you get disconnected from the server and "reconnect" to an incorrect server and end up with objects from separate databases in the same cache. This happened to us (ZC) once when we fat-fingered a ZRS database fail-over.
ZEO currently defends against this by refusing to connect to a server if the server's last transaction ID is less than the last transaction ID the client has seen. This has a couple of problems: - The test is too weak. - It makes fail-over to a slightly out of date secondary storage quite painful. I propose to add a database identifier that clients can verify. - To minimize impact to storage implementations, the database identifier will be stored under the ZODB_DATABASE_ID key of object 0 (root object). The key will be added on database open if it is absent. The value will be a configured value, or a UUID. - If a ZEO client is configured with a database identifier, then it will refuse to connect to a database without a matching identifier. - If a ZEO client is *not* configured with a database identifier, it will configure itself with the identifier of the first server it connects to, saving the information in the ZEO cache. This will at least protect against "reconnect" to the wrong server. - A ZEO client can *optionally* be configured to discard cache if it (re)connects to a server with a last transaction lower than the last one the client has seen as long as the database ID matches. - ZRS secondaries will also check database ids when (re)connecting to primaries. Comments? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
