Non-blocking distributed transaction processing system

Abstract

The prolific development of the wide variety of Internet applications forces a need for a software solution to enable access to multiple data sources while ensuring data integrity and consistency. Common Object Request Broker Architecture (CORBA) Services specified by the Object Management Group (OMG) includes a Transaction Service Specification. The Object Transaction Server (OTS) developed in this project is based on this specification. It acts as a robust system level tool to enable distributed applications to coordinate their operations into transactions. The OTS incorporates a three phase commit protocol to ensure atomicity of the transactions. This is a non-blocking protocol that ensures that operational sites participating in a transaction come to a common outcome based on the local data even in the event of (non-catastrophic) site failures.

Introduction

In response to growing demands for faster and more cost-effective application development, Information Technology (IT) organizations are turning to the distributed object computing model, which enables the reuse of business processing functionality. In order to successfully share data and functionality, and to ensure data integrity across multiple sources, organizations employing the distributed object computing model must coordinate the activities of multiple objects into transactions. Transaction processing techniques are deeply ingrained in the fields of databases and operating systems and are used to monitor, control and update information in modern computer systems.

A transaction is a unit of work composed of a set of operations on objects. A transaction is characterized by essentially its four “ACID” properties namely Atomicity, Consistency, Isolated and Durability (Tanenbaum, 1995).

The ability of transactions to hide the effects of concurrency and failures makes them appropriate building blocks for structuring reliable distributed systems in general. Industry is embracing transactions in a big way, with a near explosion occurring in usage, requirements, and sophistication of transaction processing.

Two of the most popular and competing object oriented middleware technologies, Object Management Group’s (OMG's) Common Object Request Broker Architecture (CORBA), and Microsoft’s Distributed Component Object Model (DCOM) provide well-defined infrastructure for distributed object applications (ISG, 1997). Object oriented middleware facilitates development by providing an excellent framework for application developers. Using either CORBA or DCOM, developers are provided with a higher level of abstraction, which does not require them to write any communication code. All the necessary communication code, including the marshaling of application data, is generated from the IDL compiler. Both CORBA and DCOM have their respective advantages and disadvantages, and while it is difficult to say one is better than the other in general, the choice of CORBA over DCOM for this project is based on software availability and consideration for future use by other projects.

With the growth of the Internet and sophisticated web-based applications, the need arises to coordinate application objects into transactions. Several web-based applications typically need access to multiple data sources, such as inventory, customer, or shipping data, and it is necessary to maintain data integrity across different sources to ensure consistency. These applications would benefit enormously from software services that can coordinate the activities of the application objects to ensure atomicity, consistency, isolation and durability.

CORBA Services (Object Services) is a set of interface specifications providing fundamental services that application developers may need in order to find and manage their objects and data, and to coordinate the execution of complex operations. These services augment the CORBA architecture and include, among others, a transaction service, which specifies a mechanism for CORBA objects uniformly distributed in a heterogeneous network, machine and language medium to participate in distributed transactions using a two phase commit protocol. The Object Transaction Service (OTS) simplifies the complexity of distributed transactions by providing an essential set of services integrated into one architecture, including transaction management, recovery and logging. The goal of the current project is to develop a software system for the OTS defined as part of CORBA Services. This service specification extends the CORBA model, allowing interoperability with existing CORBA-compliant application domains.

OMG’s CORBA OTS architecture specifies a transaction manager that runs the two phase commit protocol to manage its transactions. This protocol ensures that any and all changes to resources occur atomically. If a failure occurs in any one of the participating resources such that it cannot complete its part of the transaction, all other resources undo their changes. While the two phase commit protocol guarantees global atomicity, its biggest drawback is that it is a blocking protocol. This is undesirable in certain cases, where a site failure may result in certain other sites waiting indefinitely while holding locks on resources (Singhal and Shivaratri, 1994). To ensure progress despite failures, a nonblocking protocol is used to develop the OTS. Thus this project employs a three phase commit protocol (3PC) for transaction management, where the operational sites come to an outcome mutually agreed upon, even in case of site failures.

Section 2 presents background essential to understanding the project, and provides a brief outline of some related work. A detailed description of the two phase and three phase commit protocols is given and a comparative study of the two protocols is made. In Section 3, the working of the OTS and the issues in the design of the OTS based on the three phase commit protocol are discussed. Section 4 presents detailed implementation of the various components of the OTS. The example application developed for testing the OTS is presented to illustrate how an application programmer can use the OTS to build a transaction management system. Finally, conclusions and future work are presented in Section 5.