In order to motivate the need for the split and join operations, consider the requirements of CAD support for a team of engineers designing a computer chip. Since the design process may take an arbitrarily long time and involve multiple engineers, the principal engineer might like to split off responsibility for the design of specific subsystems to component engineers who can either join their results into the working chip design at a later time or choose to commit or abort their designs independently. Such requirements are not satisfied by traditional database transactions in an easy and straightforward manner but can be easily satisfied by the split/join transaction model. The code fragment below outlines how an application programmer could use the split and join operations to dynamically restructure a transaction in order to release subsystem data objects and operations to a separate transaction and, later, join with a separate transaction:
Begin_Transaction PE_Tran (1)
begin
instantiate(PE_Tran) (2)
reflect(PE_Tran, SplitJoin) (3)
...
...{ data manipulation }
...
split(CE_Tran, Subsystem) (4)
...
...{ data manipulation }
...
join(QA_Tran,*) (5)
end
Commit_Transaction {CAD_design} (6)
Line 1 declares the beginning of the principal engineer's transaction using the Begin_Transaction command found in the the base interface. This is significant, because it notifies the transaction management system that the operations between this point and the Commit_Transaction command in line 6 are to be executed atomically, according to the traditional transaction model. Thus, lines 1 and 6 bracket the transaction. The purpose of the instantiate meta interface command in line 2 is to notify the Reflective Transaction Framework of the programmers intention to ``renegotiate'' the base transaction model. The reflect meta interface command in line 3 details the terms of the renegotiation, selecting the split/join model for the transaction. The importance of the reflect command is twofold. First, it determines the control operations and semantics that are available to the transaction. In this example, the split/join model adds two new transaction control operations, namely split and join, while the begin, commit and abort commands have the same semantics as the corresponding commands in the traditional database transaction model. Second, it informs the transaction adapters in the Reflective Transaction Framework how to process transaction events on behalf of this transaction, such as lock request conflicts, transaction dependencies that might arise during execution, etc. In line 4, the application programmer uses the new extended transaction control operation split, where CE_Tran is the name of the new transaction created for the component engineer and Subsystem is the subcomponent that is to be delegated to the component engineer's transaction. Finally, in line 5, the application programmer uses the new extended transaction control operation join to merge the results and resources held by the transaction PE_Tran with an existing quality assurance program, QA_Tran.
One can see from this example that there is no description of creating the new transaction for the component engineer, no explicit delegation of the locks held on data objects in Subsystem, and no explicit delegation of the data manipulation operations pertaining to Subsystem when the application is written. With the exception of the instantiate and reflect operations, the programmer simply uses familiar transaction control operations to write the application.