Locking Semantics

Objectivity/DB has a hierarchical storage model, with the federation owning databases, which own containers, which own objects. Or, looking at it from the bottom up - objects are in containers in databases in a federation. When we looked at the locking paradigm it was immediately obvious that the best fit would by an implementation of Gray Code hierarchical locking. It adds Intention lock modes to the conventional Read (called Share) and Update (Write) locks.

Locking something automatically results in locking both higher and lower level items in an appropriate mode. When you open a federation in "Read" mode you are not blocking other users who want to update databases and containers in that federation. You actually have an IS lock on the federation. The lock monitor utility will show you that lock. If you have an OID and you open that object in "Update" mode the kernel will automatically obtain an IX lock on the appropriate database and an X lock on the container. The IX lock warns other processes that somebody is updating something in this database, but it doesn't prevent them from opening other containers in either read or update mode. The rules become slightly more complex when MROW transactions are involved and you may see C (for Concurrent) and IC locks in addition to X, S, IX, and IS.

If you want to make absolutely sure that you have safely updated a group of related objects in multiple containers you can use lock propagation to atomically obtain the update locks on all of the containers. The locks are propagated along associations, which may be between an owning container object, such as the one for a Document, and the underlying Chapter containers.

Hierarchical locking, particularly in a distributed environment, isn't easy to implement, particularly when you bring deadlock detection into the picture. When I first met Dr. Jim Gray he was very pleasantly surprised to hear that a commercial DBMS was successfully applying his ideas. One very nice side effect of this mechanism is that it dramatically reduces the amount of locking code that you see in an Objectivity/DB application. It happens implicitly and safely when you touch or update an object. When we convert applications from other ODBMSs we have to remove all of the extraneous locking code and simply make sure that the methods that set the contents of an object's fields all apply the update() method.