What's so special about AW3's OODBMS?

The AgileWiki3's ArkDb is an OODBMS withseveral unique features, the obvious one being that it tracks changes over time rather than state, providing an easy means to navigate structures in time and to restore structures to a prior state. But there's also something quite interesting about how objects are implemented.

First, let me point out a cheat. This is not a general OODBMS, but rather ArkDb only handles instances of the Rolon class and its subclasses, which is a pretty severe limitation given that Java does not support multiple inheritance. So to use it you must embrace it fully--you can't simply port a pre-existing application to it.

The key thing about the implementation is that the objects contain no data, except for an identifier. (And its a UUID--a random 128 bit string.) Rather, the data is kept in any of several caches. This is the key to speed and simplicity in a transactional environment.

The caches are aware of transactional activities. So when an abort occurs, these caches drop anything that had been changed by that transaction. And when a nested transaction commits, its list of changed items is added to the list for the parent transaction. So the cache never contains outdated data.

But it is not only the Rolons which use these caches. The btree on which everything else is built also uses a transactionally-aware cache for its blocks. This means that when an abort occurs, the btree code only needs to worry about restoring changed blocks written to the database file, without concern for the integrety of its cache.

Note also that these caches are used to retain calculated results (pathname, topic lists), and the caches support interdependencies. So when something changes, any cached results which depend on that item are dropped.

Putting this logic (and data) into the caches has made for a fast and yet reasonably simple OODBMS. This is the heart of AgileWiki3.

Bill