non-blocking distributed transaction processing system

Non-blocking distributed transaction processing system

Manjula Kommareddy *, Johnny Wong

Department of Computer Science, Iowa State University, Ames, IW 50011, USA

Received 23 April 1999; received in revised form 21 August 1999; accepted 7 February 2000

Abstract

The proli®c 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 speci®ed by the Object Management Group (OMG) includes a Transaction Service Speci®cation. The Object Transaction

Server (OTS) developed in this project is based on this speci®cation. 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. Ó 2000 Elsevier Science Inc. All

rights reserved.

Keywords: Three phase commit protocol; Object transaction server; Non-blocking; CORBA

1. Introduction

1.1. Distributed transaction processing

In response to growing demands for faster and morecost-e�ective application development, InformationTechnology (IT) organizations are turning to the dis-tributed object computing model, which enables thereuse of business processing functionality. In order tosuccessfully share data and functionality, and to ensuredata integrity across multiple sources, organizationsemploying the distributed object computing model mustcoordinate the activities of multiple objects into trans-actions. Transaction processing techniques are deeplyingrained in the ®elds of databases and operating sys-tems and are used to monitor, control and update in-formation in modern computer systems.

A transaction is a unit of work composed of a set ofoperations on objects. A transaction is characterized byessentially its four ``ACID'' properties namely Atomic-ity, Consistency, Isolated and Durability (Tanenbaum,1995).

The ability of transactions to hide the e�ects of con-currency and failures makes them appropriate building

blocks for structuring reliable distributed systems ingeneral. 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 ori-ented middleware technologies, Object ManagementGroupÕs (OMG's) Common Object Request BrokerArchitecture (CORBA), and MicrosoftÕs DistributedComponent Object Model (DCOM) provide well-de-®ned infrastructure for distributed object applications(ISG, 1997). Object oriented middleware facilitates de-velopment by providing an excellent framework forapplication developers. Using either CORBA orDCOM, developers are provided with a higher level ofabstraction, which does not require them to write anycommunication code. All the necessary communicationcode, including the marshaling of application data, isgenerated from the IDL compiler. Both CORBA andDCOM have their respective advantages and disad-vantages, and while it is di�cult to say one is better thanthe other in general, the choice of CORBA over DCOMfor this project is based on software availability andconsideration for future use by other projects.

1.2. Motivation

With the growth of the Internet and sophisticatedweb-based applications, the need arises to coordinate

The Journal of Systems and Software 54 (2000) 65±76www.elsevier.com/locate/jss

* Corresponding author.

E-mail addresses: [email protected] (M. Kommareddy),

[email protected] (J. Wong).

0164-1212/00/$ - see front matter Ó 2000 Elsevier Science Inc. All rights reserved.

PII: S 0 1 6 4 - 1 2 1 2 ( 0 0 ) 0 0 0 5 3 - 4

application objects into transactions. Several web-basedapplications typically need access to multiple datasources, such as inventory, customer, or shipping data,and it is necessary to maintain data integrity acrossdi�erent sources to ensure consistency. These applica-tions would bene®t enormously from software servicesthat can coordinate the activities of the application ob-jects to ensure atomicity, consistency, isolation anddurability.

CORBA Services (Object Services) is a set of interfacespeci®cations providing fundamental services that ap-plication developers may need in order to ®nd andmanage their objects and data, and to coordinate theexecution of complex operations. These services aug-ment the CORBA architecture and include, amongothers, a transaction service, which speci®es a mecha-nism for CORBA objects uniformly distributed in aheterogeneous network, machine and language mediumto participate in distributed transactions using a twophase commit protocol. The Object Transaction Service(OTS) simpli®es the complexity of distributed transac-tions by providing an essential set of services integratedinto one architecture, including transaction manage-ment, recovery and logging. The goal of the currentproject is to develop a software system for the OTSde®ned as part of CORBA Services. This service speci-®cation extends the CORBA model, allowing intero-perability with existing CORBA-compliant applicationdomains.

OMGÕs CORBA OTS architecture speci®es a trans-action manager that runs the two phase commit proto-col to manage its transactions. This protocol ensuresthat any and all changes to resources occur atomically.If a failure occurs in any one of the participating re-sources such that it cannot complete its part of thetransaction, all other resources undo their changes.While the two phase commit protocol guarantees globalatomicity, its biggest drawback is that it is a blockingprotocol. This is undesirable in certain cases, where asite failure may result in certain other sites waiting in-de®nitely while holding locks on resources (Singhal andShivaratri, 1994). To ensure progress despite failures, anonblocking protocol is used to develop the OTS. Thusthis project employs a three phase commit protocol (3PC)for transaction management, where the operational sitescome to an outcome mutually agreed upon, even in caseof site failures.

1.3. Road map

Section 2 presents background essential to under-standing the project, and provides a brief outline ofsome related work. A detailed description of the twophase and three phase commit protocols is given and acomparative study of the two protocols is made. InSection 3, the working of the OTS and the issues in the

design of the OTS based on the three phase commitprotocol are discussed. Section 4 presents detailed im-plementation of the various components of the OTS.The example application developed for testing the OTSis presented to illustrate how an application program-mer can use the OTS to build a transaction managementsystem. Finally, conclusions and future work are pre-sented in Section 5.

2. Background and related work

2.1. Common Object Request Broker Architecture

Today CORBA is becoming an increasingly popularstandard for distributed objects in the enterprise.Common Object Request Broker Architecture (COR-BA), a speci®cation rati®ed by the members of theOMG, speci®es a way in which developers may achieveseamless integration and interoperability of distributedobjects (Fleming et al., 1997). The OMG is a non-pro®tconsortium formed to promote the theory and practiceof object technology in distributed computing systems.The Object Management Architecture (OMA) is thecenter of all the activity undertaken by the OMG, and isa high-level vision of a complete distributed environ-ment. It consists of four components: Object RequestBroker (ORB), Object Services, Application Objects,and Common Facilities (Fig. 1). Roughly, the ORB andObject Services de®ne system-oriented components,while Application Objects and Common Facilities de®neapplication-oriented components (Schmidt, 1999).

The ORB constitutes the foundation of OMA andmanages all communication between its components,serving as the middleware that establishes the client±server relationships between objects (Keahey). It pro-vides interoperability between applications on di�erent

Fig. 1. Object management architecture.

66 M. Kommareddy, J. Wong / The Journal of Systems and Software 54 (2000) 65±76

machines in heterogeneous distributed environmentsand seamlessly interconnects multiple object systems.CORBA is the speci®cation of the functionality of theORB.

The CORBA is structured to allow integration of awide variety of object systems. It is based on the OMG'sObject Model that de®nes common object semantics forspecifying the externally visible characteristics of objectsin a standard and implementation-independent way.This enables CORBA objects (clients and servers) tocommunicate with each other easily without having anyknowledge of where each object is located, what lan-guage the object is implemented in, or what platform itresides in.

2.1.1. CORBA and JavaCORBA provides an infrastructure that enables in-

vocation of operations on objects located anywhere on anetwork as if they are local to the application usingthem. Java introduces platform-independent, low-levelcode, which, when integrated with World Wide Webprotocols and browsers, results in what are known asapplets. In the applet approach, the code for the classproviding the method is transferred across the network,run locally, and then the method is invoked on a localobject instance. These two approaches converge when amapping is de®ned from CORBA's OMG IDL to Java.When combined with a run-time system that supportsthis language mapping, the result is a Java Object Re-quest Broker (Java ORB).

The Java language binding allows implementation ofCORBA clients as applets. This enables access toCORBA objects, and potentially to legacy applicationswrapped into objects, using popular Web browsers. Javaalso provides desirable features like automatic garbagecollection, exception handling, and integrated threadsupport, not available in programming languages suchas C or C++. These features are particularly useful fordistributed systems programming. Java's high portabil-ity feature reduces development and maintenance costsand thus provides an added advantage over other pro-gramming languages.

2.1.2. Implementations of CORBAThere are many implementations of CORBA cur-

rently available, varying in the degree of compliance,quality of support, portability and availability of addi-tional features. OrbixWeb from Iona is a fully compliantcommercial Java implementation (Iona Technologies).Visibroker from Inprise is also CORBA 2.0 compliantand o�ers interoperability with Java (Inprise Corpora-tion, 1998). Other implementations include Object-Broker from Digital, Expersoft's XShell, a DistributedObject Oriented Management (DOME) system, which isalso CORBA compliant. The Java Development Kit(JDK) 1.2 software includes CORBA API and a COR-

BA-compliant ORB that allows Java applications toinvoke remote CORBA objects through the industrystandard Internet Inter-ORB Protocol (IIOP) de®ned byOMG.

2.1.3. CORBA servicesWhile the CORBA ORB provides the framework for

interaction between distributed objects, another com-ponent of the OMA, CORBA Services, de®nes system-level services that help in the management and mainte-nance of objects. These services allow application de-velopers to focus on application-speci®c requirements,without having to deal with system-level functionality.After a certain application is developed, the desiredsystem-level functionality such as security, persistence ortransactional integrity may be added via the objectsproviding these services. Applications may thus be cus-tomized to suit the demanding needs of the rapidlygrowing Internet industry.

2.2. Two phase commit protocol

OMGÕs CORBA OTS architecture speci®es a trans-action manager that runs the two-phase commit proto-col to ensure atomicity of its transactions. This protocolassumes that one of the participating processes acts as acoordinator, while the others are referred to as cohorts(Fig. 2).

The coordinator begins the protocol by sending astart transaction message to all the cohorts. The ®rstphase of the protocol is initiated when the coordinatorsends a ``Commit_Request'' message to every cohortrequesting the cohorts to commit. The coordinator thenwaits for the cohorts to reply to this request. Each co-hort replies with an `Àgreed'' or an `Àbort'' messagedepending on the success of the transaction at the cor-responding site. In the second phase, the coordinatorresponds with a ``Commit'' message to all the cohorts, ifall the cohorts had replied with an `Àgreed'' message inthe ®rst phase. Otherwise, an `Àbort'' message is sent toall the cohorts. Each cohort, after receiving a ``Commit''or `Àbort'' message, reacts accordingly, either by re-leasing all the resources and locks held, or by undoingthe transaction before releasing the resources. Finally,each cohort sends an acknowledgement to the waitingcoordinator. If the coordinator does not receive an ac-knowledgement from any cohort within a timeout pe-riod, it resends the commit/abort message to thatcohort. The transaction is completed when all ac-knowledgements are received (Singhal and Shivaratri,1994).

2.3. Three phase commit protocol

While the two phase commit protocol guaranteesglobal atomicity, the biggest drawback is that it is a

M. Kommareddy, J. Wong / The Journal of Systems and Software 54 (2000) 65±76 67

blocking protocol. If the coordinator fails, all the cohortsites will be blocked waiting for its recovery, whileholding resources. If messages are lost, the two phasecommit protocol will result in the sending of moremessages (Singhal and Shivaratri, 1994). This disad-vantage is overcome in the three phase commit protocolwhere the operational sites are allowed to agree on theoutcome of the transaction in case of site failures. Therecovering sites decide on the outcome based on theinformation stored in the local sites (independent re-covery). No site waits inde®nitely for a failed site torecover. This is achieved by adding an extra phaseknown as the prepare phase to the two phase commitprotocol. This phase comes after the ®rst phase of thetwo phase commit protocol.

The three phase commit protocol is illustrated inFig. 3. This protocol works based on an assumption thatat most one site can fail during the execution of thetransaction. The communication network is assumed tobe reliable, and point-to-point communication is possi-ble between any two operational sites. If a site fails, thenetwork is assumed to be able to detect it (for example bya timeout) and report it to the site trying to communicatewith the failed site (Singhal and Shivaratri, 1994).

The ®rst phase of this protocol is identical to that ofthe two phase commit protocol except in the event of asite failure. During the ®rst phase, the coordinator is in a

wait state after sending a ``Commit_Request'' messageto each of the cohorts. A cohort is in an abort state if ithas already sent an ``Abort'' message to the coordinator,or in a wait state if it has sent an ``Agreed'' message tothe coordinator, or in the start state if it has not receivedthe ``Commit_Request'' message from the coordinatoryet. If a cohort fails before sending an agreed message tothe coordinator, the coordinator times out, aborts thetransaction, and sends an abort message to all the othercohorts.

In the second phase, the coordinator, after receivingagreed messages from all the cohorts, sends a ``Prepare''message to all the cohorts. Otherwise, it sends an abortmessage to the cohorts. On receiving a prepare message,a cohort sends an acknowledgement to the coordinator.If the coordinator fails before sending a prepare mes-sage, it aborts the transaction upon recovery (failuretransition), and the cohorts timeout waiting for theprepare message, and abort the transaction (timeouttransition).

In the third phase, the coordinator sends a ``Commit''message to all the cohorts after receiving acknowledge-ments from all the cohorts. A cohort that has received acommit message commits the transaction. However, if acohort fails before sending an acknowledgement inphase 2, the coordinator times out and sends abortmessages to all the cohorts. The failed cohort, upon

Fig. 2. Finite state automata illustrating the two phase commit protocol.


recovery, will undergo a failure transition and aborts thetransaction.

2.4. Related work

2.4.1. Version and Integration Control SystemThe Java language environment, the World Wide

Web, and CORBA are complementary software tech-nologies, which when used together provide a powerfulset of tools for developing and deploying user-orienteddistributed applications. The Version and IntegrationControl System (VICS) is an example of a user-orienteddistributed application developed at the University ofTexas Applied Research Laboratory (Evans and Rog-ers, 1996). It provides a multi-user, distributed softwarecon®guration management capability, and was initiallyimplemented using HTML forms and the CommonGateway Interface (CGI). Two researchers, Eric Evansand Daniel Rogers used this application as a ``guineapig'' and re-implemented a subset of its functionality

using Java and CORBA for testing the combined use ofthe two technologies.

Since the ORB software takes care of the details ofconveying operation requests and responses, objects andtheir clients may interact without regard to their re-spective locations, host or compiler data representa-tions, source languages, host/operating system speci®cs,or underlying communication mechanisms. This enablesdistributed applications to incorporate components thatare written in di�erent source languages and are exe-cutable on di�erent host and operating system plat-forms. This ¯exibility allows such applications to becomposed out of legacy or third-party software as wellas newly developed software.

One problem that CORBA does not solve is that ofdeploying a distributed application's component pro-grams. This problem is solved by implementing the user-side client software as Java applets, which use CORBAfor most remote operations with the rest of the appli-cation's software components. The users would trans-parently download the applets when they are needed,

Fig. 3. Finite state automata illustrating the three phase commit protocol.


thus removing the need for manually distributing andinstalling any application-speci®c software. This projectdemonstrated that the combination of CORBA andWWW-based Java applets can be a good, practicalframework for developing distributed applications(Evans and Rogers, 1996).

2.4.2. Distributed transactions using CORBAVisiBroker Integrated Transaction Service from

Inprise Corporation simpli®es the complexity of distrib-uted transactions by providing an essential set of services-including an implementation of the CORBA TransactionService, recovery and logging services, integration withdatabases and legacy systems, and administration facili-ties-within a single, integrated architecture (Vits, 1998).

PowerBroker, CORBAPlus Transaction Service fromExpersoft, lets developers build transactional integrityinto distributed object applications deployed acrossthe Internet, intranets, or corporate networks (Fleminget al., 1997).

3. System design

3.1. System design goals

The intent of the current project is to develop a ro-bust software system for managing transaction pro-cessing. The design goals of this system include:· Transparency: The details of the transaction process-

ing system should be hidden from the user of an ap-plication based on the OTS Server. The user shouldnot have to deal with the initiation or terminationof transactions manually.

· Ease of use: A distributed application developer in-tending to use to the OTS to incorporate distributedtransaction management techniques into the applica-tion, should be able to do so with minimal e�ort.

· Robustness: The system should be resilient to di�erenttypes of failures.

· Portability: The system developed should be portableto di�erent host system architectures and should beable to function well across heterogeneous platforms.

· Interoperability: The system should be able to inter-operate with other CORBA 2.0 compliant ORB im-plementations.

· Support for maintenance and deployment: It should beeasy to deploy components of applications developedusing the OTS across a network. The system shouldbe easy to maintain and should support easy upgrad-ing of the applications developed.

3.2. Overview of Object Transaction Service

This section presents the design details of the ObjectTransaction Service (OTS) de®ned in the Common

Object Services Speci®cations (COSS). The speci®cationprovides a wide spectrum of implementation choiceswhile keeping the design goals in view.

The OMG's OTS de®nes interfaces that allow mul-tiple, distributed objects to participate reliably in a dis-tributed transaction. It brings together two powerfulparadigms, the transaction paradigm, and the objectparadigm. While the transaction paradigm is essential todeveloping reliable distributed applications, the objectparadigm is the key to productivity and quality in ap-plication development (Venturimilli, 1998). The inter-faces de®ned by the transaction service enable theobjects invoking its services to either commit all changestogether or to rollback all changes together, even in thepresence of (non-catastrophic) failure. Thus these dis-tributed objects cooperate with each other via theTransaction Service to ensure atomicity of a transaction.

The requirements of the Transaction Service arecompletely de®ned by the speci®ed interfaces, and donot place any restrictions on the number of objectsparticipating in a transaction, the topology of the client±server application, and on how the objects are distrib-uted over the network. In a typical scenario, a client ®rstbegins a transaction by issuing a request to an objectde®ned by the Transaction Service. This results in thecreation of a transaction context that de®nes the scopeof a transaction, and is shared implicitly by the objectsparticipating in the transaction. All the requests issuedby the client within that transaction context form part ofthe same transaction, and are carried out atomically.Eventually, when the client decides to end the transac-tion (by issuing another request), the changes producedas a consequence of the client's requests would either becommitted or rolled back, depending on the success ofthe events.

In contrast to the above scenario, where the trans-action context is transmitted implicitly to the objectswithout direct client intervention, the Transaction Ser-vice also supports an explicit propagation of the trans-action context. In such a case, the client passes thehandle to the transaction context as a parameter to theobject at the time of making the request.

In addition to the above, the client has a choice ofmaking a request outside the scope of a transaction. TheTransaction Service does not provide for a transactioncontext in this case, and it is up to each object to de-termine its behavior when invoked outside the scope of atransaction.

Fig. 4 shows the basic entities involved in an appli-cation supported by the OTS (COSS).

A transactional client or a transaction originator is anarbitrary program that can invoke operations of manytransactional objects in a single transaction.

An object whose behavior is a�ected by being in-voked in the scope of a transaction is known as atransactional object. A transactional object typically


contains or indirectly refers to persistent data that canbe modi®ed by a transaction.

A transactional operation is de®ned as an operationon an object that participates in the propagation of thecurrent transaction.

A recoverable object is a transactional object thatregisters an object known as a ``Resource'' with theTransaction Service, and participates in the TransactionService protocols. The Transaction Service Speci®cationincorporates a two phase commit protocol to ensurethat the resource objects either commit or rollbackatomically. These protocols are invoked on the regis-tered resource objects by issuing requests to them. Arecoverable object retains in stable storage certain in-formation at critical times in its processing. When arecoverable object restarts after a failure, this informa-tion may be used during its recovery procedure to bringitself to a stable state.

A transactional server is a collection of one or moretransactional objects. These objects do not have recov-erable states of their own, and do not participate in thecompletion of a transaction.

A recoverable server is a collection of objects at leastone of which is recoverable. It participates in the commitprotocols of the Transaction Service.

In summary, the overall OTS architecture may beviewed as consisting of an application domain and asystem domain. The application domain consists ofcomponents of the OTS Server that application devel-opers would modify to suit the application's needs.These components include the Transactional Client andthe Recoverable Server. The system domain comprisesof the OTS server core components that the applicationdomain components use to initiate and terminate atransaction. Examples of these components include theFactory, Control, Coordinator, and Terminator objects.

The following scenario demonstrates the events thattypically occur in a transaction. The transaction origi-nator creates a transaction using a TransactionFactory;a Control object is created and returned. The Controlobject provides access to a Terminator and a Coordi-nator. The Terminator is used by the transaction origi-nator to commit or rollback a transaction. TheCoordinator is used to coordinate the operations com-prising the transaction. A recoverable server registers aResource object with the Coordinator. The Resourceimplements the protocols driven by the TransactionService. A Resource uses a RecoveryCoordinator incertain failure cases to determine the outcome of thetransaction and to coordinate the recovery process withthe Transaction Service.

The Resource object, as de®ned in the TransactionService Speci®cation implements a two phase commitprotocol. This protocol ensures the global atomicity ofthe operations involved in a transaction. However, theOTS developed in this project modi®es the speci®cationto suit real time needs and incorporates a three phasecommit protocol to ensure atomicity. As explained inSection 2.2, unlike the two phase commit protocol, thethree phase commit protocol is a non-blocking protocolthat enables participating sites to come to a commonoutcome even in the case of (non-catastrophic) sitefailures.

3.2.1. Features in the design of the Transaction ServiceThe Transaction Service provides operations to con-

trol the scope and duration of a transaction, and to al-low multiple objects to be involved in a transactionthrough which some of these objects may change theirinternal states in an atomic way (COSS).· Transaction models: The Transaction Service de®ned

by OMG supports two transaction models. The ¯at

Fig. 4. Application including basic elements.


transaction model deals with only top-level transac-tions, while the nested transaction model providessupport for a ®ner granularity of recovery throughthe use of nested transactions. Nested transactionsinvolve one or more subtransactions (child transac-tions) embedded in the scope of a parent transaction.In this case, if an operation performed within a sub-transaction fails, only the subtransaction is rolledback. The parent transaction has the opportunity tocorrect or compensate for the problem and completeits operation.

· Transaction termination: A transaction is terminatedby issuing a request to commit or rollback the trans-action. Typically, a transaction is completed by theclient that originates it. But it is possible for any par-ticipant in a transaction to force the transaction to berolled back, if a failure is encountered.

· Transaction integrity: The Transaction Service inter-faces may be implemented to provide a checked oran unchecked transaction behavior. In the formercase, transaction integrity is guaranteed by the imple-mentation, whereas in the latter case, the TransactionServer may rely entirely on the application to providetransaction integrity.

· Transaction context: Each ORB-aware thread is asso-ciated with a transaction context that is null, if thethread is not part of a transaction. Multiple threadsmay be associated with the same transaction simulta-neously in the same execution environment or in dif-ferent execution environments. This transactioncontext can be transmitted to transactional objects ei-ther implicitly or explicitly during the invocation of atransactional operation.

· Synchronization: An implementation of the Transac-tion Service may support synchronization by provid-ing a protocol by which a resource object may benoti®ed prior to invoking the two phase commitprotocol within the coordinator with which it isregistered.

3.3. Design evaluation

This section presents an evaluation of the systemdeveloped with respect to the design goals. The follow-ing observations have been made:· The OTS is easy to use and does not require applica-

tion developers to change any portion of the OTS todevelop distributed applications. The handling of thedetails of a transactional operation are hidden fromthe user of the distributed application.

· The OTS is robust owing to the non-blocking natureof the three phase commit protocol.

· System maintenance is simpli®ed by the object-orient-ed approach in the design of the Transaction Server.

· By choosing a CORBA 2.0 compliant ORB imple-mentation that supports Internet Inter-ORB Protocol

(IIOP), the system is made interoperable with otherCORBA 2.0 compliant ORBs.

4. Implementation and testing

4.1. Implementation issues

This section discusses the implementation details ofthe various components speci®ed in the design section.VisiBroker, a CORBA compliant ORB implementationby Inprise is used as the communication layer. Visi-Broker provides automatic multi-threading of serverobject implementations. When several clients try to ac-cess the OTS Server simultaneously, each of the clientswill be served automatically by a di�erent workerthread. VisiBroker thus relieves the application pro-grammers of the task of thread manipulation.

Section 3.2 described the design principles of theOTS, and the various options that the COSS providedfor the Transaction Service Speci®cation. These optionsprovide to the implementers of the OTS Server, a varietyof programming and/or transaction models. As part ofthe programming model, both explicit and implicitpropagation of transaction contexts have been de®ned.While implicit propagation model has the advantagethat the propagation of the transaction context istransparent to the user, it restricts all operations to betransactional. Explicit propagation model, on the otherhand, requires the application to handle the propagationof the transaction context, thereby providing the ap-plication developer with the ¯exibility of allowingindividual operations to be transactional or non-trans-actional. In the current project, the explicit propagationmodel has been chosen to implement the OTS Server.

As part of the transaction model, the TransactionService Speci®cation de®nes both nested and ¯at trans-action models. Although nested transaction modelprovides ®ner granularity for transaction control, thecurrent project is developed using the ¯at transactionmodel, considering the wide usage of ¯at transactions inthe industry.

An important aspect of the implementation of theOTS Server is its non-blocking nature. The TransactionService Speci®cation incorporates a two phase commitprotocol to deal with the transaction management. Thisimplementation replaces the two phase commit with athree phase commit protocol to ensure that participatingsites do not block inde®nitely in case of site failures. Themodi®cations are described in detail in the next section.

4.2. CosTransactions Module

The CosTransactions Module de®nes the interfaces ofthe various components comprising of the OTS Server,


including exceptions, and the various structures andenumerations used to support the interfaces. Changeshave been made to the de®nition of the Resource in-terface in the CosTransactions module to replace thetwo phase commit protocol with the three phase commitprotocol. The following is a description of the variousinterfaces used to develop the OTS Server and theirfunctionality.

4.2.1. Interfaces1. TransactionFactory interface is provided to allow the

transaction originator to begin a transaction.· create: This function allows the creation of a new

top-level transaction. The new transaction man-agement and participation are controlled usingthe returned Control object.

2. Control interface allows explicit management ofpropagation of a transaction context. Each controlobject is associated with one speci®c transaction.· get_terminator: This operation provides an acces-

sor to a Terminator object, which supports opera-tions to end the transaction by rolling back orcommitting the transaction.

· get_coordinator: This is an accessor method for aCoordinator object, which is used to registerResource objects for the transaction associatedwith the Control. In both the above cases, anUnavailable exception may be thrown if theControl object is not able to provide the requestedobject.

3. Terminator interface supports operations to end atransaction.· commit: If all the participants in the transaction

have agreed to commit, this allows a transactionto be committed and the operation terminates nor-mally. Otherwise, the transaction is rolled back,and a TRANSACTION_ROLLEDBACK excep-tion is raised.

· rollback: This call causes the transaction to berolled back, which causes all changes to recover-able objects made in the scope of this transactionto be undone.

4. Coordinator interface is provided to support opera-tions that participants in a transaction use. Theseparticipants may be recoverable objects or sub-coor-dinators that manage other recoverable objects.· get_status: This operation returns the status of the

transaction associated with the target object.· is_same_transaction: This operation returns true if

both the target object and the parameter object re-fer to the same transaction.

· register_resource: This operation is used to registerthe speci®ed resource as a participant in the trans-action associated with the target object. It returns aRecoveryCoordinator that can be used by this re-source during recovery. At the termination of the

transaction, the resource receives requests to com-mit or rollback the updates performed as part ofthe transaction.

5. RecoveryCoordinator interface supports operationssuitable for a recovery process in certain situations.A RecoveryCoordinator object is associated with aspeci®c resource and may be used by that resourceduring recovery.· replay_completion: This operation may be required

in certain failure cases, where the coordinator is in-formed that the commit or rollback operationshave not been performed on the resources.

6. Resource interface de®nes the operations invoked bythe transaction service on each registered resource.These calls related to the various phases in the threephase commit protocol.· commit_request: This operation is invoked to begin

the three phase commit protocol on the resource.The response of the resource to this call is storedin the vote result. The resource may vote ``read-only'', ``commit'' or ``rollback'' depending on thestate of the transaction associated with this re-source. The transaction service does not performany additional operations on the resource after thisrequest is received.

· prepare: This operation begins the second phaseof the protocol, when the coordinator receivespositive responses from all the resources. In thisoperation, the resource is requested to prepareto commit the updates made as part of thistransaction.

· rollback: This operation is called to undo thechanges made by the resource in this transaction,and the resource forgets all about the transaction.

· commit: This operation is called to commit thechanges made by the resource in this transaction.

· commit_one_phase: This operation is invoked whenonly one resource is involved in a transaction.

· forget: This operation is invoked only if the re-source raised a heuristic outcome exception to roll-back, commit, or commit_one_phase operations.Once the exception has been addressed, the coor-dinator issues this command on the resource sothat the resource forgets all knowledge of thetransaction.

4.2.2. ExceptionsCosTransactions module de®nes certain exceptions to

inform participants in a transaction of exceptional sit-uations. These exceptions are categorized into StandardExceptions and Heuristic Exceptions.

Standard exceptions add to the already existing list ofexceptions to CORBA.1. TransactionRequired Exception: This indicates that a

request carries a null transaction context, and thatan active transaction context is required.


2. TransactionRolledback Exception: An operation rais-es this exception to indicate that the transaction asso-ciated with the request has already been rolled back,or has been marked no rollback.

3. InvalidTransaction Exception: An operation can raisethe InvalidTransaction exception to indicate that therequest carried a transaction context that is not valid.

Heuristic exceptions are raised to report incorrect heu-ristic decisions. These decisions are normally made byone or more participants in unusual circumstances, suchas communication failures that prevent normal pro-cessing, without waiting for the consensus outcome de-termined by the Transaction Service.1. HeuristicRollback Exception: This exception is raised

by a commit operation on a resource to indicate thata heuristic decision was made to rollback all relevantupdates.

2. HeuristicCommit Exception: This is raised by a roll-back operation on a resource to indicate that all rel-evant updates have been committed.

3. HeuristicMixed Exception: A request raises a Heuri-sticMixed exception to report that a heuristic decisionwas made and that some relevant updates have beencommitted, while some others have been rolled back.

4. HeuristicHazard Exception: This exception reportsthat a heuristic decision may have been made, the sta-tus of all relevant updates is not known, and for thoseupdates whose status is known, either all have beencommitted or all have been rolled back.

5. WrongTransaction Exception: When a request carrieda wrong transaction context, the ORB raises this ex-ception.

Besides the above, the module also de®nes a set of ad-ditional exceptions: Inactive Exception, NotPreparedException, NoTransaction Exception, InvalidControlException, and Unavailable Exception.

4.2.3. DatatypesThe module de®nes the following datatypes:Status is an enumeration datatype with possible

values as StatusActive, StatusMarkedRollback, Status-Prepared, StatusCommitted, StatusRolledBack, Status-Unknown, StatusNoTransaction, StatusPreparing,StatusCommitting, StatusRollingBack.

Vote is an enumeration with values VoteAgreed,VoteCommit, VoteRollback, VoteReadOnly.

4.3. Application example

4.3.1. Mini bank account systemThe application example developed is a mini bank

system, with two servers, a Savings Server, and aChecking Server, distributed in the network. The Clientis a Java application that provides a Graphical UserInterface (GUI) for a customer of the bank to operateon one or both of his accounts. Interfaces are provided

through the GUI to open a new account, withdraw fromor deposit to the account, check balances, and totransfer money from one account to the other. TheSavings and the Checking Servers are implemented asRecoverable Object servers that manage the savings andthe checking accounts, respectively. The OTS Serverprovides the transaction service required by the opera-tions of the bank.

Any bank operation would involve the user at thefront end entering his/her name, choosing the transac-tion type, and inputting the details of the transaction(amount of money, etc.), and invoking the operation. Atthe back end, both the Checking and the Savings Serversare object servers that manage active account objectswhose details are permanently stored in an ORACLEdatabase. Each server maintains its own database. Theobject servers use JDBC to interact with the database.The functionality of commit and rollback of Recover-able Objects is implemented using private workspace.Whenever the database is accessed, the relevant data iscopied into a temporary bu�er, and the updates aremade to this bu�er without actually changing the orig-inal database. When a commit request is made, thechanges in the temporary bu�er are carried over tothe database, where they are stored permanently. On theother hand, if the coordinator instructs the recoverableobject to rollback, the data in the temporary bu�er isdiscarded without modifying the contents of thedatabase.

In the above setup (Fig. 5), the OTS Server acts as themiddleware coordinating the various components par-ticipating in the transaction, and ensuring that the dataintegrity is maintained. For example, if a user tries toopen an already existing account, or if an attempt ismade to withdraw a sum of money exceeding theamount present in the account (either during a withdrawor a transfer operation), the OTS will ensure that nochanges are made to the database, that might corruptthe consistency of the database. In case one of the objectservers crashes, the three phase protocol ensures that theother server does not wait inde®nitely for the crashedserver to recover, but makes a decision based on theavailable details. The recovered server too makes a de-cision to commit or abort that is consistent with thedecision of its counterpart. For example, if a user initi-ates a transfer of a certain amount from the savingsserver to the checking server, and if the savings servercrashes in the middle of the transaction, the coordinatortimeouts waiting for a response from the savings server.Depending on which phase of the protocol the timeoutoccurs, the coordinator decides to commit or abort thetransaction, and invokes the corresponding operationon the checking server. When the savings server is up, itdoes a recovery operation based on its local data, andcompletes the transaction accordingly, ensuring that theresultant data in both the databases is consistent. In


other words, either both checking and savings serverswould have committed the transfer operation, or noneof them.

4.4. Testing

The example application presented above has beenused for testing the OTS Server. The client applicationof the mini bank system was used to feed various inputsto the system, and the output checked for the correct-ness of the overall system. Server crashes were simulated(through user intervention) at various stages of atransaction, and the results obtained were matchedagainst the expected outcome.

5. Conclusions

5.1. Summary

This report presented the details of the design, de-velopment and testing of the OTS Server as speci®ed inthe CosTransactions module of the CORBAServicesspeci®cation, with modi®cations to replace the twophase commit protocol with the three phase protocol forimproved performance in case of site failures. The fol-lowing conclusions can be drawn based on the experi-ences with the system developed:· Portability of the system is achieved through the use

of VisiBroker, a CORBA 2.0 compliant ORB, andJava, a platform independent language.

· By using an OTS Server, transaction processing ap-plication developers can avoid having to spend alarge amount of software development time for trans-action management. The loose coupling between theOTS and the application servers is a feature that aidsin the ease of application development.

· The system was found to be robust with respect toserver crashes. In the example application developed,if one of the bank servers crashed in the middle of a

transaction (simulated by killing the server applica-tion), the coordinator does not block waiting forthe crashed server to respond to its message, but endsthe transaction based on the data available at thetime the server crashed.

5.2. Future work

The OTS developed serves as a good software systemfor coordinating distributed transactions. This systemmay be further enhanced by adding one or more of thefollowing features:1. Nested transaction model: The CosTransactions mod-

ule also de®nes a transaction model that uses nestedtransactions. Nested transaction model allows cre-ation of subtransactions within a transaction, andprovide for ®ner granularity of recovery than ¯attransactions. When a subtransaction fails, only themodi®cations made within the scope of that subtrans-action need to be rolled back, and the other subtrans-actions at the same level or at a higher (parent) levelneed not follow suit. The parent transaction maychoose other alternatives to overcome the failure,and complete the transaction successfully. This fea-ture provides for improved fault tolerance, and higherthroughput may be achieved by executing severalsubtransactions in parallel in a multi-threadedenvironment.

2. Use of Java applets: The client application may be de-veloped as a Java applet, which can then exploit theWWW infrastructure to enable easy deployment ofclient software.

3. Other CORBA Services: CORBAServices speci®ca-tions also include Concurrency Control Serviceamong others. The Concurrency Control Service en-ables multiple clients to coordinate their access toshared resources. Multiple transactions, trying to ac-cess con¯icting resources simultaneously, may be co-ordinated by using the Transaction Service togetherwith the Concurrency Control Service to ensure con-sistency of these resources.

Fig. 5. Mini-bank system using OTS.


References

(COSS) Transaction Service Speci®cation. http://www.omg.org/corba/

sectrans.html.

Evans, E., Rogers, D., 1996. Using Java Applets and CORBA for

Distributed Application Development. Applied Research Labora-

tories, The University of Texas at Austin. http://www.arlut.utexas.

edu/�islwww/ird/JavaCORBA.html.

Fleming, K., Aslam-Mir, S., Damstra, J., Vilicich, M., 1997. Distrib-

uted Transactions using CORBA, Expersoft Corporation. http://

www.expersoft.com/Resources/WPapers/distributed.htm.

Inprise Corporation, 1998. VisiBroker Product Documentation. http://

www.inprise.com/techpubs/books/vbj/vbj30/pdf_index.html.

International Systems Group, 1997. Middleware ± The Essential

Component for Client/Server Applications. http://www.openvms.

digital.com/openvms/whitepapers/middleware/isgmidware.html.

Iona Technologies, OrbixWeb 3.1 The Internet ORB. http://www.

iona.com/info/products/docs/oweb-whitepaper2.pdf.

Keahey, K., A Brief Tutorial on CORBA. www.cs.indiana.edu/hyplan/

kksiazek/tuto.html.

Schmidt, D., 1999. Overview of CORBA. www.cs.wustl.edu/�schmidt/

corba-overview.html.

Singhal, M., Shivaratri, N., 1994. Advanced Concepts in Operating

Systems. McGraw-Hill, New York.

Tanenbaum, A.S., 1995. Distributed Operating Systems. Prentice-Hall,

Englewood Cli�s, NJ.

Venturimilli, K., 1998. A Software System for Distributed Transaction

Processing using OTS. Department of Computer Science, Iowa

State University.

(Vits 98) Inprise Corporation, 1998. VisiBroker Integrated Transaction

Server 1.1. http://www.inprise.com/techpubs/books/its/its11/index.

html.

What is CORBA? 1998. Object Management Group. www.omg.org/

corba/whatiscorba.html.

What is Java IDL? http://java.sun.com/docs/books/tutorial/idl/intro/

intro.html.

Manjula Kommareddy received the M.S. degree in computer science inAugust 1998 from the Iowa State University, Iowa. In July 1998, shejoined Newmonics Corporation in Ames, IA and is currently a soft-ware engineer. Her current research activities are in distributed sys-tems. Other areas of work includes the use of Java technology asbusiness solution in the real-time applications.

Dr. Johnny Wong is a Full Professor of the Computer Science De-partment, Iowa State University at Ames, Iowa, USA. His researchinterests include Operating Systems, Distributed Systems, Telecom-munication Networks, Broadband-Integrated Services Digital Net-works, Concurrency Control and Recovery, Multimedia andHypermedia Systems, Intelligent Multi-Agents Systems, IntrusionDetection. He has been an investigator for research contracts withTelecom Australia from 1983 to 1986, studying the performance ofnetwork protocols of the ISDN. During this period, he has contributedto the study and evaluation of the communication architecture andprotocols of ISDN. From 1989 to 1990, he was the Principal Investi-gator for a research contract with Microware Systems Corporation atDes Moines, Iowa. This involved the study of Coordinated MultimediaCommunication in ISDN. In Summers 1991 and 1992, Dr. Wong wassupported by IBM corporation in Rochester. While at IBM, he workedon the Distributed Computing Environment (DCE) for the Applica-tion Systems. This involved the integration of communication proto-cols and distributed database concepts. Dr Wong is also involved inthe Coordinated Multimedia System (COMS) in Courseware MatrixSoftware Project, funded by NSF Synthesis Coalition Project to en-hance engineering education. From 1993 to 1996, he is working on aresearch project on a knowledge-based system for energy conservationeducation using multimedia communication technology, funded by theIowa Energy Center. From 1995±1996, he was supported by the AmesLaboratory of the Department of Energy (DOE), working in Mid-dleware for Multidatabases system. Currently, he is working on In-telligent Multi-Agents for Intrusion Detection and Countermeasuresfunded the Department of Defence (DoD), Database Generating andX-Ray Displaying on the World Wide Web Applications funded byMayo Foundation and CISE Educational Innovation: Integrated Se-curity Curricular Modules funded by the National Science Foundation(NSF).


non-blocking distributed transaction processing system

Documents