The transaction concept has been used effectively in traditional database systems to synchronize concurrent access to a shared database and provide reliable access in the face of failures. A transaction is an atomic unit of work against the database, consisting of a sequence of data manipulation operations, typically read and write, along with control operations that affect the execution of the transaction. The control operations found in the traditional database transaction model are Begin_Transaction, Commit_Transaction, and Abort_Transaction. ACID properties of transactions (atomicity, consistency, isolation, and durability) guarantee correct concurrent execution as well as reliability [HR83]. The flexibility of a given transaction model depends on the way these four ACID properties are combined, along with the control operations available to the transaction. Although powerful, it is commonly accepted that the traditional transaction model found in conventional database systems is lacking in functionality and performance when used for advanced application domains [Elm93]. Some of the considerations are that transactions in these domains are longer in duration and often require the release of intermediate results to other transactions during execution, requiring a relaxed notion of atomicity. This is the case, for example, in computer-aided design and manufacturing (CAD/CAM) applications. In some application domains, the property of isolation between transaction has to be relaxed to allow cooperation among transactions in order to accomplish a common task. This is the case in computer-supported cooperative work environments. Hence, over the last five years a number of extended transaction models have been introduced to accommodate the diverse requirements of advanced application domains [PKH88,MP92,RC92,CR92,,WR93]. These models introduce new transaction control operations, such as the operation Split and Join operations introduced by the split/join transaction model [PKH88], and they associate "broader" interpretations of the ACID transaction properties to provide enhanced functionality while increasing the potential for improved performance.
While the potential benefits of these new extended transaction models have been known for some time, few practical implementations of these models have been developed [Moh94]. One reason for the lack of practical implementations is that conventional TP monitors have a closed interface, accepting only traditional database transaction control operations and an apparently rigid implementation, making it difficult, if not impossible, to implement extended transaction models. Systems programmers attempting to implement extended transaction behaviors are often frustrated by the complexity of the task, and, even if they succeed, the closed interface locks in the extended functionality, preventing application programmers from using the new extended transaction behaviors. As a result, to date most extended transaction models remain mere theoretical constructs with no practical implementation [Moh94].