There exist only a small number of research efforts on implementing extended transaction functionality, spirit to the Reflective Transaction Framework. Two noteworthy systems for implementing extended transaction models are ASSET [BDG+94] and TSME [GHKM94]. Similar to our framework, these systems are designed to facilitate the implementation of extended transaction models. However, they simply present the user with a closed application interface and a fixed selection of mechanisms from which a predetermined set of extended transaction models can be implemented. In our approach, the user is presented with a flexible framework in which the functionality and interface for an extended transaction model can be created, rather than a fixed selection of mechanisms from which particular extended transaction models can be selected.
ASSET [BDG+94] provides a set of new language primitives that enable the realization of various extended transaction models in an object-oriented database setting. In addition to the standard database control operations Begin, Commit and Abort, ASSET provides three new primitives: form-dependency to establish structure-related inter-transaction dependencies, permit to allow for data sharing without forming inter-transaction dependencies, and delegate which allows a transaction to transfer responsibility for an operation to another transaction. Using these new primitives, it is possible to synthesize certain extended transaction control operations within the program. However, the task of synthesizing new control operations is a skill that each programmer would necessary have to learn and the task must be repeated for each transaction that requires the operation.
TSME [GHKM94] consists of a transaction specification facility that understands TSME's transaction specification language, and drives the transaction management mechanism to configure a run-time system in order to support specific extended transaction models. The transaction management mechanism is programmable, but uses templates to describe existing extended transaction models. TSME is a toolkit based system, in which certain expressions in the specification language are mapped to certain configurations of pre-built components in the transaction management mechanism. If the needs of the application fall outside of this pre-built set, there is no recourse for the programmer -- even though the transaction facility may be fully capable of implementing the required behavior.
The research of Stroud and Wu [SW95,Str93] is also related to the Reflective Transaction Framework, in that their work to implement synchronization and recovery properties for atomic data types also takes a metaobject protocol approach. They use metalevel programming, in the form of Open C++ [CM93] language, to implement a clean separation between application code and the synchronization/recovery code needed to guarantee atomicity, and thus make it possible for programmers to select new schemes for ensuring atomicity by simply introducing new metaobjects into the system. As in the Reflective Transaction Framework, the non-functional aspects of atomic data types such as synchronization and recovery are implemented at the metalevel, while the functional aspects such as object operations are implemented at the base level. In this work and ours, reflection is utilized as a special form of indirection which links the base level and metalevels together. As for reflective systems, most of the work on reflection has been on procedural reflection, where the meta-level directly implements the base-level. One notable exception is Rok Sosic's work on Dynascope [Sos92b,Sos92a]. Dynascope is a programming environment for directing the execution of traditional compiled languages. Program directing involves two processes, an executor and a director. When a program is executed in the Dynascope environment, the executor process generates an execution stream which the director process monitors. When selected events occur, similar to breakpoints, computation is shifted from the application to the Director where event-specific processing is performed on behalf of the application. This approach is similar to that of the Reflective Transaction Framework, in that adapters respond to selected transaction significant events and perform processing on behalf of the transaction. However, unlike transaction adapters, the Dynascope director does not maintain a causal connection with underlying application, and it requires a special-purpose programming environment for the necessary instrumentation.