Dale Skeen

A Formal Model of Crash Recovery in a Distributed System

A formal model for atomic commit protocols for a distributed database system is introduced. The model is used to prove existence results about resilient protocols for site failures that do not partition the network and then for partitioned networks. For site failures, a pessimistic recovery technique, called independent recovery, is introduced and the class of failures for which resilient protocols exist is identified. For partitioned networks, two cases are studied: the pessimistic case in which messages are lost, and the optimistic case in which no messages are lost. In all cases, fundamental limitations on the resiliency of protocols are derived.

An efficient, fault-tolerant protocol for replicated data management

A data management protocol for executing transactions on a replicated database is presented. The protocol ensures one-copy serializability. i.e., the concurrent execution of transactions on a replicated database is equivalent to some serial execution of the same transactions on a non-replicated database. The protocol tolerates a large class of failures, including: processor and communication link crashes, partitioning of the communication network, lost messages, and slow responses of processors and communication links. Processor and link recoveries are also handled. The protocol implements the reading of a replicated object efficiently by reading the nearest available copy of the object. When reads outnumber writes, the protocol performs better than other known protocols.

A recovery algorithm for a distributed database system

We describe a reliability algorithm being considered for DDM, a distributed database system under development at Computer Corporation of America. The algorithm is designed to tolerate clean site failures in which sites simply stop running. The algorithm allows the system to reconfigure itself to run correctly as sites fail and recover. The algorithm solves the subproblems of atomic commit and replicated data handling in an integrated manner.

The inherent cost of nonblocking commitment

A commitment protocol orchestrates the execution of a distributed transaction, allowing each participant to “vote” on the transaction and then applying a pre-specified rule to decide the outcome (commit or abort). A nonblocking commitment protocol is able to correctly terminate a transaction at all operational participants in the presence of any number of benign processor failures. Herein, we derive strong lower bounds for both nonblocking protocols and their less fault-tolerant blocking counterparts. Results on message complexity are both surprising and encouraging: the message complexities of the two classes of protocols are identical. Results on time complexity were less encouraging: nonblocking protocols are approximately 50% more expensive. However, we show how to overlap nonblocking executions of interfering transactions and thereby reduce their extra cost.

Increasing availability in partitioned database systems

A partitioning of a distributed database! system (DDBS) occurs when the DDBS is djvided into two or more subsets such that no member of one subset can communicate with any member of another. When a system becomes partitioned, there are two possibilities. The system can shut off activity and wait for the connection8 to be reestablished, or it can adjust its behavior and attempt to continue running. Since a major goal of distributed systems is to be resilient in the face of failures, the first alternative is clearly undesirable. “his paper explores approaches to the second alternative.

Patterns of communication in consensus protocols

This paper presents a taxonomy of consensus problems, based on their safeness and liveness properties, and then explores the relationships among the different problems in the taxonomy. Each problem is characterized by the communication patterns of protocols solving it. This then becomes the basis for a new notion of reducibility between problems. Formally, problem <italic>P</italic><subscrpt>1</subscrpt> reduces to problem <italic>P</italic><subscrpt>2</subscrpt> whenever each set of communication patterns of a protocol for <italic>P</italic><subscrpt>2</subscrpt> is the set of communication patterns of a protocol for <italic>P</italic><subscrpt>1</subscrpt>. This means intuitively that any protocol for <italic>P</italic><subscrpt>2</subscrpt> can solve <italic>P</italic><subscrpt>1</subscrpt> by relabeling local states and padding messages. Consequently, the message complexity (measured in number of messages) of <italic>P</italic><subscrpt>1</subscrpt> is not greater than the message complexity of <italic>P</italic><subscrpt>2</subscrpt>. Our method of characterizing and comparing problems is the principal contribution of this paper.

Determining the last process to fail

A total failure occurs whenever all processes cooperatively executing a distributed task fail before the task completes. A frequent prerequisite for recovery from a total failure is identification of the last set (LAST) of processes to fail. Necessary and sufficient conditions are derived here for computing LAST from the local failure data of recovered processes. These conditions are then translated into procedures for deciding LAST membership, using either complete or incomplete failure data. The choice of failure data is itself dictated by two requirements: (1) it can be cheaply maintained, and (2) it must afford maximum fault-tolerance in the sense that the expected number of recoveries required for identifying LAST is minimized.

Thrifty Execution of Task Pipelines

SummaryA sequence of tasks that must be performed on a sequential database can be scheduled in various ways. Schedules will differ with respect to the number of accesses made to peripheral storage devices and the amount of memory space consumed by buffers. Buffer requirements are discussed for task schedules that avoid accesses to peripherals storing the sequential database. The relationship between certain thrifty scheduling policies and loop jamming, a standard code optimization technique, is also identified. Application to UNIX pipelines and to file processing is discussed.