Abstract not found

Compensating transactions are intended to handle situations where it is required to undo either committed or uncommitted transactions that affect other transactions, without resorting to cascading aborts. This stands in sharp contrast to the standard approach to transaction recovery where cascading aborts are avoided by requiring transactions to read only committed data, and where committed transactions are treated as permanent and irreversible. We argue that this standard approach to recovery is not suitable for a wide range of advanced database applications, in particular those applications that incorporate long-duration or nested transactions. We show how compensating transactions can be effectively used to handle these types of applications. We present a model that allows the definition of a variety of types of correct compensation. These types of compensation range from traditional undo, at one extreme, to application-dependent, special-purpose compensating transactions, ...

Abstract not found

An asynchronous approach is proposed for replica control in distributed systems. This approach applies an extension of serializability called epsilon-serializability (ESR), a correctness criterion which allows temporary and bounded inconsistency in replicas to be seen by queries. Moreover, users can reduce the degree of inconsistency to the desired amount. In the limit, users see strict 1-copy serializability. Because the system maintains ESR correctness (1) replicas always converges to global serializability and (2) the system permits read access to object replicas before the system reaches a quiescent state. Various replica control methods that maintain ESR are described and analyzed. Because these methods do not require users to refer explicitly to ESR criteria, they can be easily encapsulated in high-level applications that use replicated data. 1 Introduction Data replication offers the benefits of autonomy, performance, and availability. Unfortunately, ensuring that the replica...

This paper addresses the performance of distributed database systems. Specifically, we present an algorithm for dynamic replication of an object in distributed systems. The algorithm is adaptive in the sense that it changes the replication scheme of the object (i.e. the set of processors at which the object is replicated), as changes occur in the read-write pattern of the object (i.e. the number of reads and writes issued by each processor). The algorithm continuously moves the replication scheme towards an optimal one. We show that the algorithm can be combined with the concurrency control and recovery mechanisms of a distributed database management system. The performance of the algorithm is analyzed theoretically and experimentally. On the way we provide a lower bound on the performance of any dynamic replication algorithm.

In a variety of applications, we need to keep track of the development of a data set over time. For maintaining and querying these multiversion data efficiently, external storage structures are an absolute necessity. We propose a multiversion B-tree that supports insertions and deletions of data items at the current version and range queries and exact match queries for any version, current or past. Our multiversion B-tree is asymptotically optimal in the sense that the time and space bounds are asymptotically the same as those of the (single-version) B-tree in the worst case. The technique we present for transforming a (single-version) Btree into a multiversion B-tree is quite general: it applies to a number of hierarchical external access structures with certain properties directly, and it can be modified for others.

This paper exposes the concurrency control problem in groupware when it is implemented as a distributed system. Traditional concurrency control methods cannot be applied directly to groupware because system interactions include people as well as computers. Methods, such as locking, serialization, and their degree of optimism, are shown to have quite different impacts on the interface and how operations are displayed and perceived by group members. The paper considers both human and technical considerations that designers should ponder before choosing a particular concurrency control method. It also reviews our work-in-progress designing and implementing a library of concurrency schemes in GROUPIUT, a groupware toolkit.

Database designers often point out that eager, update everywhere replication suffers from high deadlock rates, message overhead and poor response times. In this paper, we show that these limitations can be circumvented by using a combination of known and novel techniques. Moreover, we show how the proposed solution can be incorporated into a real database system. The paper discusses the new protocols and their implementation in PostgreSQL. It also provides experimental results proving that many of the dangers and limitations of replication can be avoided by using the appropriate techniques. 1 Introduction Existing replication protocols can be divided into eager and lazy schemes [GHOS96]. Eager protocols ensure that changes to copies happen within the transaction boundaries. That is, when a transaction commits, all copies have the same value. Lazy replication protocols propagate changes only after the transaction commits, thereby allowing copies to have different values. ...

Abstract not found

Introduction This chapter gives an overview on multilevel transactions and its generalization toward open nested transactions. The main features of these transaction models are the following: first, semantic properties of operations can be exploited to relax the isolation of concurrent transactions; second, as a consequence, atomicity is achieved by compensation rather than state-based undo; and third, subtransactions can be made persistent independently of their commit state, that is, global visibility of their updates. Advanced transaction models and new correctness criteria for transaction executions have been proposed for the following reasons (and possibly further reasons that are not mentioned here): 1. to provide better support for long-lived activities in advanced DBMS applications, 2. to relax the classical ACID paradigm, for example, provide more flexibility as to when updates are made visible to concurrent transactions, 3. to support cooperation between the members