Encina TP Monitor Interface

For our current implementation of the Reflective Transaction Framework we are using Encina, a commercial TP Monitor distributed by the Transarc Corp. Transaction services for Encina are provided by the Encina Toolkit [Tra], which is composed of a small number of transaction middleware service modules, including: TRANSACTION SERVICE MODULE (TRAN) that provides transaction execution control and default transaction control operations (begin, commit, abort), LOCK SERVICE MODULE (LOCK) that provides a logical locking package to guarantee transaction isolation and, LOG SERVICE MODULE (LOG) that provides write-ahead log support for transaction updates and crash recovery. The transaction middleware service modules of the Encina Toolkit provide the basic building blocks of the TP monitor reference architecture [GR93, pp. 21], and have been used by a number of computer system providers to implement various TP monitors, including IBM's CICS/6000 TP monitor, DEC's ACMSxp TP monitor [BCDW95] and, of course, the Encina TP monitor [Cor91].

Each module in the Encina Toolkit provides access to its transaction services and behaviors through a relatively simple and uniform API. In addition, each module provides an event facility which allows the user to register a function, referred to as the transaction callback function, that is to be called, or delivered, when a certain transaction event occurs. An event is simply a happening of interest, and in Encina this includes transactions changing execution states and requesting resources. Common examples include a transaction attempting to commit or abort, and a transaction requesting a lock on a database item. When an events occurs, transaction execution is stopped and the registered transaction callback function is invoked, passing all data pertaining to the event. Transaction execution is blocked until the callback function returns. Thus, the delivery of a transaction callback passes both data and execution control to the registered function, enabling the function to selectively modify default system handling of the transaction event. We combine this existing transaction callback facility and TP Monitor API to form the causal-connection between the modules in the Encina Toolkit and the transaction adapters in the Reflective Transaction Framework. Transaction adapters use the callback facility for reification, and the standard Toolkit API for reflective updates.

While we had access to Encina source, our implementation did not require changes to the fundamental data structures or core functions of the Toolkit. In a few cases, however, it was necessary to extend the callback function argument list to pass additional information from the TP monitor to the adapter for reification. Because of the availability of transaction callbacks and a rich API command set in the Encina Toolkit, we were able to fully integrate the Reflective Transaction Framework into Encina. An extended transaction running on Encina behaves just like a standard ACID transaction. Having opened the implementation of Encina, we can adjust the extended transaction's behavior as needed. Extended transactions, generally speaking, retain most of their base-level semantics provided by Encina and simply gain some additional behavior, such as semantic notions of conflict or new extended transaction control operations; looking back on the split/join example, the model added the operations split and join, while the operations begin, commit, and abort retain their original meaning (implementation).

Our Encina implementation has demonstrated the practicality of the Reflective Transaction Framework. A question which naturally arises is how portable the framework is to TP monitors not constructed from the Encina Toolkit, and to transaction services found in relational and object-oriented database servers. As pointed out in Section 3.1, to make the Reflective Transaction Framework portable, we designed transaction adapters in the context of the TP monitor reference architecture to use only a small, widely supported, set of API commands. However, to answer this question concretely, we are compiling a list of required transaction functionality and API commands for reflective update, along with the necessary upcalls for reification. When complete, we will compare this list against other transaction facilities to assess the portability of the Reflective Transaction Framework to other systems.