Application programmers develop transactional applications using a set of transaction model-specific verbs, or transaction control operations. For example, classic database transactions are initiated by the control operation Begin-Transaction, and terminated by either a Commit-Transaction or Abort-Transaction control operation. Extended transactions, on the other hand, often introduce additional operations to control their execution, such as the operation Split-Transaction introduced by the split/join transaction model [PKH88], or the operation Join-Group introduced in the cooperative group model [MP92,RC92]. Indeed, a transaction model defines both the control operations available to a transaction as well as the semantics of these operations. For example, whereas the Commit-Transaction operation of the classic database transaction model implies the transaction is terminating successfully and that its effects on data objects should be made permanent in the database, the Commit-Transaction operation of a member transaction in a cooperative transaction group implies only that its effects on data objects be made persistent and visible to transactions that belong to the same group.
To accommodate the diversity between different extended transaction models, we introduce a separation of programming interfaces to the TP monitor. This separation follows the open implementation approach [Kic92], pioneered in the meta-object protocol [KdRB91], in which the functional interface is separated from the meta interface. The purpose of the meta interface is to modify the behavior, or semantics, of the functional interface. In our separation of interfaces, presented figuratively in Figure 5 and described below, both the transaction demarcation interface and extended transaction interface are functional, subdivided for clarity only.
The separation of programming interfaces to the TP monitor provides a way not just to talk about existing transaction models, but to also introduce new extended transaction behaviors and interfaces. Default transaction behaviors remain available through the standard transaction demarcation interface. New extended transaction behaviors can be defined using the meta interface, and made available to to application through the introduction of new extended transaction control operations in the extended transaction interface. The extended transaction interface, then, augments the transaction demarcation interface with new extended control operations.
Using the Reflective Transaction Framework, TP systems programmers don't need to ``second guess'' the specific needs of application developers, or restrict the applicability of the TP monitor to a subset of extended transaction models, but can use the meta interface to add new extended transaction models as necessary. Application programmers are not constrained to a fixed set of control operations or a fixed transaction model, but are free to select the appropriate transaction model to meet the needs of the application. Moreover, they can access these new extended transaction behaviors using programming skills they already posses, namely through transaction control operations.
