Synchronizing group transaction with rendezvous in a distributed Ada environment

The group communication paradigm (multicast communication) has been proposed as a useful interaction mechanism in many distributed applications. In this paradigm, a client sends a service request to a group of processes (it multicasts a request), and then all the members of the group receive the request and cooperate among them to provide the service. On the other hand, transactions allow a client to interact with different services in an atomic way. Transactions exhibit isolation, failme atomicity and permanence of effect of client operations. We have developed a model that integrates transactions with the group communication paradigm. Drago is a distributed extension of Ada implementing the group paradigm. Transactional Drago is an extension of Drago that implements our model. As in Ada, Drago processes interact via rendezvous, while client and server transactions traditionally have interacted via remote procedure call (RPC). Besides this, RPC presents some shortcomings that can be overcome using rendezvous. For these reasons, we find necessary to use the rendezvous as the synchronization mechanism between client and server transactions. We present in this paper which are the advantages and difficulties of this approach and how it has been introduced in our system. 1 I N T R O D U C T I O N Transactions [10] are a mechanism to provide fault tolerance. The3' provide useful properties for constructing reliable distributed applications. These properties are failure atomicity, isolation and data consistency. On °This work has been par t ia l ly funded by the Spanish Research Counci l (CICl 'T~. contract number T1C94C02-01. Permission to make digital/hard copy of all or part of this work lbr personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. © 1998 ACM 0-89791-969-6/98/0002 3.50 the other hand, the group communication paradigm, in particular Causal and Totally Ordered Communication (CATOCS) [4], has also been proposed as an adequate way to build fault tolerant applications such as cooperative and replicated ones. There has been some controversy about which of those mechanisms is more adequate to build fault tolerant applications. In [6] some limitations of CATOCS are identified, in particular, the applicability of CATOCS is limited to those applications where application-level consistency is required. One of these limitations is the lack of serialization ability for groups of messages corresponding to different operations. CATOCS just provides ordering properties between individual messages, but some applications require handling groups of messages as a serial unit. This inability to group operations also affects to the handling of higher-level errors. For example, in replicated applications CATOCS guarantees tha t every server receives the message, but if some of the servers are unable to fulfill the operation due to some reason (e.g. storage problems), the programmer has to write a lot of code to coordinate this partial failure, because other replicas will be processing the message. In other words, total ordering does not guarantee anything once messages are delivered. However, atomic transactions allow a server to abort (undo) easily a set of operations in this scenario. Another limitation identified in the paper is that many semantic ordering constraints cannot be expressed in CATOCS, for instance: linearizability [14] and serializability. In summary, CATOCS provides complementary fault tolerance to the one provided by transactions. Despite the shortcomings discussed above, CATOCS offers some benefits [3] missing in the transaction model: • Its framework allows the construction of (efficient) distributed cooperative servers. • It improves process and data availability by means of replication. Schiper and Ravnal [19] state that transactions and group commumcation are not antitheticM. Others, [20] conclude that b,~th ( 'ATO( 'S and lransac'lion models are useful, and that some applications are better solved with CATOCS, while others with transactions. Our opinion is that both paradigms are complementary and that it is necessary a system offering both mechanisms, in an orthogonal way. So, our approach is to integrate both paradigms. We have developed a new transaction model, Group Transactions I that integrates both approaches. We have followed a linguistic approach starting from a fault-tolerant distributed language, Drago [1, 16], that implements the group paradigm. Transactional mechanisms have been incorporated in a new version of the language called Transactional Drago. Drago is a distributed extension of Ada. It allows to program two kinds of groups: replicated groups that provide control and data availability, and cooperative groups that provide a framework to program cooperative applications with high throughput and low latency. Our model presents some novelties. First of all, the integration of both paradigms by means of transactional groups that provide atomic services to client transactions. Secondly, a service is provided as a subtransaction that is distributedly executed by all the members of the group, that can cooperate among them to provide the service. In the traditional transaction model a service request is accepted by a single server, that can call concurrently to other servers, but each of these calls are executed as different subtransactions, preventing cooperation among them. Ada concurrency support is kept in Transactional Drago. In our model, concurrency is allowed within a transaction, that is, a transaction can be multithreaded. Besides this, the server is able to enforce an order to multiple concurrent interactions, in spite of the misuse of the server calls on the client side, providing data consistency in the server. One of the problems found when designing our model was the election of the synchronization mechanism to be used between client and server transactions. Remote procedure call (RPC) [10, 21, 8, 15] is the synchronization mechanism commonly used. When a RPC is issued, a client transaction borrows a flow of control in the server to execute the procedure that will perform some work on server data. The execution of concurrent RPCs does not impose any order to the server to serve client requests other than the order imposed by the internal synchronization mechanisms available in the server (e.g. locks). On the other hand, the rendezvous model is traditionally used in message based concurrent applications with a client-server structure. The client asks for a service sending a message to the server and the server decides when to accept the service requested by that message (establishing in that way the rendezvous), thus enforcing an order to serve requests. Even though the Ada95 Distributed Annex ('hoosos tho RP( ' modol for distributed communication. Drago provides a remote rendezvous approach, not l ' I ' t :~lls;I , t i , , l , gl.,tl[)~. I,lr;I)os(~(t ill [9]. iS ~. d i f f e r e n t m o d e l , d e ~ u i l e t h r ~ i m i l a r i u c , , f th(" n a m e s . only because 'of its expressiveness, but also due to reasons related to the group communication and the replicated group paradigm. Members of replicated groups must receive the same requests in the same order and this c a n b e achieved much more easily with a unique flow of control. Thus, replicated group members can decide deterministically what to do, in contrast with uncontrolled requests (RPC). Transactional groups introduce new reasons to use the rendezvous approach. In our model, clients and servers interact by means of rendezvous to allow a server to impose a protocol of calls to its clients. This paper will focus on the use of rendezvous to synchronize client and server transactions in a distributed Ada environment. Some effort has been devoted to study how to implement atomic actions [18, 23, 5] in Ada-95. However, they just deal with the isolation property, and they do not care about failure atomicity and recovery. In addition, these works center in how to use Ada mechanisms to implement them, while ours centers on transactions (so we deal with recovery) and their integration with the group paradigm. Furthermore, our work is focused in the introduction of linguistic features. There are other systems providing atomic transactions as language mechanisms or libraries [15, 8, 21], but they use RPC as synchronization mechanism between client and server transactions and they do not support the group paradigm. They only allow concurrency within a transaction running concurrent subtransactions, thus preventing any cooperation among them. This paper is organized as follows. Section 2 introduces transactions. Section 3 summarizes the main features of Drago. Section 4 presents our model, group transactions, while in section 5 we propose how to synchronize client and server transactions in the context of this model. Finally, we present our conclusions in section 6. 2 T R A N S A C T I O N S A transaction is a sequence of server operations requested by a client that are executed atomically, that is, the whole sequence is executed or the effect is as it never has been executed. Transactions preserve four properties (known as ACID properties [13]): atomicity, consistency, isolation (serializability) and durability. Atomicity guarantees that the effect of the transaction is all or nothing in spite of failures. Isolation ensures that two concurrent independent transactions will not interfere. Durability ensures that once a transaction has finished its effect will continue despite failures. To deal with isolation, concurrency control mechanisms are used. while to preserve atomicity and