Academia

When you read this remember Mr. OLTP makes no pretense of academic rigour and this humble effort should only be considered as at best a managerial review of some, not all, of the work going on this field. As Mr. OLTP explores and writes more (and of course is told more by you, dear reader) then this page will grow. Please, therefore if you do find some interesting publications in this field do report them. Credit, as ever, will be given.

Distributed Parallelized Calculations

To make things simple, as an illustration, the source code examples found elsewhere on this site are designed to do one thing then another. They could of course be organized to do both things (update the databases) together. Things would then go, if not twice as quick, at least as fast as the slowest branch of the transaction. There would be no worries about an individual failure since everything is protected by Transactions.

Transactions provide a simplification of the model for distribution of complexed calculations, especially where some intermediate storage is required. Exceptions need not now be coded for explicitly, rather a Transaction Monitor can be used.

Needless to say, the Massively Paralleled Distributed Computing people are discovering Transactions. A good example of this can be seen in FADI, which is a fault tolerant environment for distributed processing systems. FADI integrates a checkpointing/rollback mechanism with an already well known parallel processing system PVM. It builds upon a prior system known as Condor. More can be found at the University of Tennessee and in papers on "Time Warp" Parallel Processing.

Camelot

Camelot (the name is from CArnegie-Mellon Low Overhead Transaction) was developed at Carnegie-Mellon University on the back of the Mach Operating System project and the earlier work by the likes of Liskov [Liskov]. The core of Camelot was a library and a set of 'C' macros that allow transaction interchanges to be made using Mach RPCs. The Transactions, which could be nested, were bracketed with BEGIN_TRANSACTION and END_TRANSACTION statements. Camelot was used by Avalon, a C++ like language, which introduced the concept of server. The server construct looked like a C++ Class, except that the data held within them persistent, that is the data within the server survive over the may invocations of the program. These servers could be invoked and communicated with in a transactionally secure way both remotely and locally. They were thus the building blocks for a distributed object oriented database.

More information can be found on Camelot in the Camelot and Avalon book [Eppinger, Mummert & Spector] and in a review paper [Spector].

Arjuna

Mr. OLTP has been asked "Is there a freely available TPM which can be studied, like BSD for operating systems or Ingres for Relational Database Managers?" Well actually there is and it is Arjuna from Newcastle University. Arjuna presents a good starting point for the serious study of a TPM. Arjuna is available to run on Intel based commodity computers running Linux, so no expense need be spared.

Arjuna, at face value, has a lot in common with the Camelot project in that the TPM supports nested transactions working with a modest object oriented database. It uses its own flavour of RPC which it makes transactional. Arjuna, however, employs a wholely C++ interface to the transactional model, with an extensive use of C++'s Classes and Inheritance.

Arjuna never became a commercial product as such, although it was rumoured that a major computer company were interested at one stage. Development continued under Professor Shrivastava's tutelage and friends at Bluestone tell me that it was was commercialised as an Object Transaction Managers (OTM) eventually (still named Arjuna Limited). This like other OTM has moved on to be the Transaction Manager in an Enterprise Java Beans (EJB) Container when it was acquired by Bluestone. In a bringing-things-full-circle type of way, the large computer company that was interested early on, HP, has now bought Bluestone. Bluestone were then "sunset" by HP (at about the time of the Compaq acquistion) but Arjuna lives on and Arjuna Technologies was founded to provide OLTP based Middleware.

Arjuna's approach to Transactions is based on the use of the Language C++'s Class and in particular Class's Constructor and Destructor mechanisms. Originally designed as a mechanism to manage the Class's private dynamic storage, Constructors are functions within a Class which are invoked when the Class's object is made and Destructors are invoked when the object is finished with (called "going out of scope"). There was thus no need to use specific dynamic memory management routines such as UNIX's malloc(3) and free(3), a fine thing, says Mr. OLTP, with vivid memories of a double free bug. So, in Arjuna, Transactions are begun in Constructors and Committed in Destructors. As ever there are special functions to Rollback any current Transactions. Although it is possible to code your own Transactional Constructors and Destructors it is easier to use Inheritance, another feature of C++. Inheritance allows the creation of some Class, say shape, and then, with Inheritance create new ones with added features or constraints. For example, Class triangle can inherit Class shapes basic geometry defining data and functions. Inheritance can be multiple too (although, Mr. OLTP observes, you can go mad and totally obfuscate things). Arjuna thus allows the creation of complexed data manipulating and distributed Classes which inherit transactional control. In fact, the Arjuna Transactional Class inherits its necessary locking properties from a further more fundamental Lock Management Class.

More information can be obtained from [Parrington & al], a review paper published by the authors of Arjuna, which together with other information and the source can be found on-line at Arjuna's web site. Arjuna is now part of JBoss, which itself is part of Red Hat, the Linux distribution company.

Point to Note

In the area of OLTP, Reuter, an academic, or is it Gray, who now sadly is no longer with us but was in charge of a research and development laboratory, make a very important point in their excellent book [Reuter & Gray]. Often academic progress is a reinvention of things which are at the heart of an operating system, database manager or transaction monitor already. They illustrate it by retelling the story of Galileo demonstrating telescopes to his patrons whilest outside his window people were buying and selling mass-produced ones.

Academic study in this area does allow for a certain openness for although algorithms may be rediscovered they are published, rather than languishing in some hidden commercial sensitive dark corner.

$Date: 2008/07/03 12:36:10 $