Being objective about database replication

One of the key original architectural elements of Lotus Notes is its ability to replicate documents across different copies of the same database. [They copies must explicitly be set up as "replicas" of each other. If you're unfamiliar with this, see brief introductions at The History of Notes and Domino or NotesDesign and Notes Architecture, Internals and History or its mirrored page Notes Architecture, Internals and History for even more links.]

The Notes replication process is outstanding. It ensures that the different databases are kept in synchronization. It has stood the test of time since the late 1980s or early 1990s, and from Notes R4 onwards got even more granular with field-level replication (only individual fields that are newly created or updated or deleted need be replicated, not entire documents, a major performance booster). Notes databases have always been "rich-content document oriented" and -- unlike hierarchical and relational transactional databases -- by design no record locking occurs to prevent concurrent updates. Therefore when a given document is updated in multiple copies of the database, at the next replication cycle you can get document "replication conflicts" (multiple versions of the given document containing different fields and/or field contents). In essence, these conflicts must be manually resolved.

I've been deeply interested in database architectures ever since 1978, when I went to the IBM Rochester, Minnesota, development laboratory to gain pre-announcement training in the IBM System/38. This introduced a machine-based (microcode level) database which was essentially a relational database built in, below the operating system level. Don't get me started on the unique S/38 architecture, which later got enhanced and morphed into the IBM AS/400 and more recently the IBM iSeries Server -- now rebranded the IBM System i (what brand name next year?). And how I believe that Lotus Domino on this server is "the best of all possible worlds" ... Someahere along the way, the unnamed built-in relational database picked up the DB2 moniker ... I could go on forever!

Although I don't specialize in database, I've kept up my interest, and try to keep abreast of major happenings. One of the mnore frequently visited useful links pages on my web site is the database section: see http://asiapac.com.au/Links/Database.htm or its mirror http://notestracker.com/Links/Database.htm

The above is all leading to the db4o open source object database for Java and .NET and specifically to point out a quite interesting article:

• Inside the db4o Database - Replication made easy

It says that "Besides being open source, db4o's features include an easy-to-grasp API, equally lucid persistence model, and the fact that it is a true object database (not an object/relational mapping database). Add to this its invisible transactioning and its adherence to ACID (atomicity, consistency, isolation, and durability) behavior, and you have an embeddable database that concentrates a lot of power in a small area. ... The entire db4o library is provided in a single .JAR file (or .DLL if you're using .NET), and you'll typically find yourself handling better than 90 percent of your database work with about 10 API calls." It sounds like great stuff.

The article then goes on to explain the workings of the db4o "replication" capability, and even talks about the handling of replication conflicts -- shades of Lotus Notes replication! But, of course, this is in the realm of object relational databases and with a Java and .NET programmability.