Problem
-------
In multi-database configurations, ZODB applications can unintentionally
create cross-database references. The causes include moving (rather
than copying) an object between containers, storing an object in a
session database and later moving it to the main database, and using a
persistent object for a catalog index when the catalog is located in
another database.
Unintentional cross-database references can cause significant problems.
For example, references from non-volatile objects to volatile session
objects will break when the session expires, leading to application errors.
In a project I am working on, my team decided that configuring our
application to use a multi-database was too risky unless we had some way
to prevent unintentional cross-database references.
Proposed Solution
-----------------
I propose an optional "seat belt" for cross-database references in ZODB.
The seat belt, when enabled, gives applications an opportunity to veto
the creation of cross-database references. Application policy will
specify which cross-database references to allow.
Proposed Mechanism
------------------
The ZODB.DB.DB constructor will accept a new parameter, "check_xrefs",
that defaults to False. When check_xrefs is True, the cross-database
reference seat belt is enabled. "xref" is short for "cross-database
reference".
When the cross-database reference seat belt is enabled for a database,
ZODB publishes events (using the zope.event package) every time an
object that contains cross-database references changes. Event
subscribers have the opportunity to veto the cross reference by
generating an exception.
The published event will conform to the following interface.
class ICrossDatabaseReferenceEvent(Interface):
source = Attribute("The object holding the reference")
target = Attribute("The target of the reference")
Each database in a multi-database has its own check_xrefs setting. The
setting applies only to the objects contained in that database. This
allows developers to specify, for example, that arbitrary references
from the main database to the volatile session database are disallowed,
while arbitrary references from the volatile session database to the
main database are allowed.
A possible risk of the proposed mechanism is that an event subscriber
could wake up ghosts as a side effect. Implementers probably need to
avoid that.
Conclusion
----------
The proposed new feature is designed to help developers create more
robust ZODB applications by enforcing cross-database reference policy.
I hope it can be included in ZODB 3.9.
Shane
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
