Distributed transaction processing has become a very important part of distributed computing. Our research originating from the development of the peer-to-peer transactional paradigm identified a number of open issues not only relating to peer but to transaction processing in general. Such issues were the need for reconciling chained and unchained transactions, context management, multiprotocol and transaction-model independent transaction managers and the manipulation of transactional objects. In more detail our work has concentrated and contributed to the following research topics of distributed transaction processing.

Our Work on distributed transactions is build around the peer-to-peer model.  The peer-to-peer (P2P) transactional environment supports a general model of distributed computation.  The application programs are distributed and cooperate, as equals, to execute the transactions of a distributed computation. It is a different and a more general model than that supported in the Client-Server (C/S) paradigm. This richness, however, has certain ramifications in most modules that support a distributed transactional environment. The peer-to-peer model affects the transactional paradigm, the communication paradigm, transaction management, and commit processing as well as other related functions. Work on this area originated from IBM Research Triangle Park and during my stay at IBM I have contributed in every aspect of this model's development.  Finally, in 1994 an IBM book publication, authored by myself, A. Citron and k. Britton, presented the complete P2P transactional architecture embedded in IBM's SNA communication protocol. This architecture is being implemented by all IBM's and some non-IBM industrial transactional offerings. In  "The Peer-to-Peer Cooperative Distributed Transactional Environment" we describe that work in an SNA independed manner providing insights and comparisons to the client-server model. We present a comprehensive study of IBM's peer-to-peer distributed transactional environment.  This includes discussion of the peer-to-peer transactional model and its approach towards the new challenges posed by this widely-used paradigm.  The paper, also shows that the peer-to-peer can be thought of as a distributed cooperative operating environment. Other parts of our work describing how the peer-to-peer handles certain transactional modules (i.e., transaction identifier management)  can be found in the last two references below while other modules such as the description of  IBM's PN commit protocol and transactional negotiation protocols are in the pipeline. The work in this area gave also birth to the following research topics.

Related Publications:

Distributed transactions require transaction processing support either from their communications protocols or from protocols at some higher layer.  The peer-to-peer environment is supported by IBM's SNA (i.e., LU6.2) and follows the chained transactional paradigm. As OSI/TP began specifying the flows for transactional support, the notion of unchained transactional support as opposed to the chained nature of LU6.2 transactions gradually developed (OSI/TP supports both chained and unchained transactions). This makes the coexistence of applications requiring both kinds of transaction processing support on a platform that supports only chained transactions problematic and reduces the interoperability of communication protocols providing transactional support. Our work identified and addressed the above problems by identifying the extra functionality provided by unchained transactions over chained transactions. It then showed how a protocol/platform that provides only chained transactional support can provide the functionality of unchained transactions, and without using the notion of chained or unchained transactions at the API. It also studied an efficient way by which protocols providing only chained support can provide the functionality of unchained transactions using the X/Open TX API based on OSI/TP's Chained and Unchained Functional Units. In all solutions the notion of "context" as is presented below was instrumental. 

Related Publications:

Recent trends indicated that the existing process/thread support provided by systems in unsuitable for a range of application programs. A new processing paradigm is now evolving to fill this gap and to provide more flexibility to distribute tasks across processes/threads. This emerging paradigm allows multiple program threads to work on the task, each thread to work on a different task, or  a thread to work on multiple task for greater design flexibility or due to system constraints such as real-time demands and a high load on tasking. We use the definition of context to capture the notion of logical locus of control. The context of the work being currently executed must be identifiable uniquely by the application, the Resource Managers and the Transaction Manager because each context represents different work. In this work we have identified this emerging paradigm, defined context, the Context manager and its user interface, and show how context is used for local and distributed transaction processing. We high-light the role of context in a multithreaded, real-time, high tasking operating environment, provide different  practical styles of transaction management using context, and show how to use context management to solve deadlocks, protocol violations and loopbacks.  The result of this work has been published in "Context Management and its Applications to Distributed Transactions". The VM operating Shared File System has been enhanced to provide a version of the context management support presented in this work. An expanded version of the prementioned paper has been submitted for further publication. This work also clarifies XOPEN's/XA++ recently identified problems regarding the vagueness surrounding the notion of  "thread of control".

Related Publications: