ZODB.Architecture.Storage Interface
Documentation
Classes that implement the Storage interface provide access to a particular low-level storage mechanism. In BoboPOS 1, this was called the "Simple Database" interface, and it consisted mostly of a mapping interface. In BoboPOS2, transaction semantics crept into the interface, which was no longer defined explicitly. The Storage interface almost entirely removes the original mapping interface, replacing it with a new interface that is highly transaction-centric.
Mixing store, commitVersion, abortVersion and undo.
A single transaction may perform combination of store, commitVersion, abortVersion, and undo operations. The mixing of these operations on the same objects is ambiguous.
To simplify the task of implementing storage managers, the following rule is provided:
Only one operation is allowed to impact an object id in a single transaction unless the storage supports undo and all of the operations that affect an object are undo operations.
Application interfaces
Synchronization
Storages must provide reliable storage of data in a multi-threaded database environment that may use multiple storages. Storages must protect access from multiple threads in two ways. First, with a few exceptions, no two threads should access a single storages methods at one time. This may be accomplished by employing instance locks that are carefully managed by a storage implementation, or a special mix-in class such as the Sync.Synchronized class distributed with ExtensionClass may be used. Second, a two-phase commit protocol must be supported by blocking or rejecting certain operations when a storage is committing.
A Storage may be in two states, �committing� and �not committing�. (See the "State" diagram.) A storage is placed into the committing state by invoking it�s tpc_commit method. If this method is invoked while the storage is already committing, then the method blocks until the storage leaves the committing state. Several storage operations are state dependent, as shown in figure 4. For example, it is an error to invoke the store method while in the not committing state. If an operation is invalid for the current state, a StorageTransactionError is raised.
Many of the storage methods are not state dependent. A non-state dependent method may be blocked, especially in the committing state.