Hendrik Decker

Managing Transaction Conflicts in Middleware-based Database Replication Architectures

Database replication protocols need to detect, block or abort part of conflicting transactions. A possible solution is to check their writesets (and also their readsets in case a serialisable isolation level is requested), which however burdens the consumption of CPU time. This gets even worse when the replication support is provided by a middleware, since there is no direct DBMS support in that layer. We propose and discuss the use of the concurrency control support of the local DBMS for detecting conflicts between local transactions and writesets of remote transactions. This allows to simplify many database replication protocols and to enhance their performance

MADIS: a slim middleware for database replication

Data replication serves to improve the availability and performance of distributed systems. The price to be paid consists of costs caused by protocols by which a sufficient degree of consistency of replicated data is maintained. Different kinds of targeted applications require different kinds of replication protocols, each one requiring a different set of metadata. We discuss the middleware architecture used in the MADIS project for maintaining the consistency of replicated databases. Instead of reinventing wheels, MADIS makes use of basic resources provided by conventional database systems (e.g. triggers, views, etc) to achieve its purpose, to a large extent. So, the underlying databases can perform more efficiently many of the routines needed to support any consistency protocol, the implementation of which thus becomes much simpler and easier. MADIS enables the databases to simultaneously maintain different metadata needed for different replication protocols, so that the latter can be chosen, plugged in and exchanged on the fly as online-configurable modules, in order to fit the shifting needs of given applications best, at each moment.

Inconsistency-Tolerant Integrity Checking

All methods for efficient integrity checking require all integrity constraints to be totally satisfied, before any update is executed. However, a certain amount of inconsistency is the rule, rather than the exception in databases. In this paper, we close the gap between theory and practice of integrity checking, i.e., between the unrealistic theoretical requirement of total integrity and the practical need for inconsistency tolerance, which we define for integrity checking methods. We show that most of them can still be used to check whether updates preserve integrity, even if the current state is inconsistent. Inconsistency-tolerant integrity checking proves beneficial both for integrity preservation and query answering. Also, we show that it is useful for view updating, repairs, schema evolution, and other applications.

Modeling, Measuring and Monitoring the Quality of Information

Semantic properties that reflect quality criteria can be modeled by integrity constraints. Violated instances of constraints may serve as a basis for measuring quality. Such measures also serve for monitoring and controlling quality impairment across changes.

Classifying integrity checking methods with regard to inconsistency tolerance

We define and examine six classes of methods for integrity checking: case-based, compositional, relevance-based, simplification-based, total-integrity-dependent, and measure-based ones. Each, except the penultimate, corresponds to a particular form of inconsistency tolerance. Inconsistency measures provide a new approach to integrity checking and inconsistency tolerance. For many methods, proofs or disproofs of their inconsistency tolerance become easier and more transparent by our classification. In general, a better understanding of inconsistency-tolerant integrity checking is achieved

k -bound GSI: a flexible database replication protocol

Several previous works have proven that there is no way of guaranteeing a snapshot isolation level in symmetrical replicated database systems without blocking transactions when they are started. As a result of this, the generalized snapshot isolation (GSI) level was defined, relaxing a bit the freshness of the snapshot being taken when a transaction is initiated in its local replica. This enhances performance, since transactions do not need to get blocked, but in some cases will increase the abortion rate. This paper proposes a flexible protocol that is able to bound the degree of snapshot outdateness from a relaxed GSI to the strict one-copy equivalent SI. Additionally, it proposes an optimistic solution where transactions do not block, and only need to be re-initiated when their optimistic start fails. Such re-initialization is made very soon and only rolls back the first transaction accesses, without waiting for the transaction completion. Finally, if 1CSI is not enough, this protocol is also able to manage transactions with serializable isolation, if such a level is requested.

A relaxed approach to integrity and inconsistency in databases

We demonstrate that many, though not all integrity checking methods are able to tolerate inconsistency, without having been aware of it. We show that it is possible to use them to beneficial effect and without further ado, not only for preserving integrity in consistent databases, but also in databases that violate their constraints. This apparently relaxed attitude toward integrity and inconsistency stands in contrast to approaches that are much more cautious wrt the prevention, identification, removal, repair and tolerance of inconsistent data that violate integrity. We assess several well-known methods in terms of inconsistency tolerance and give examples and counter-examples thereof.

Toward a uniform cause-based approach to inconsistency-tolerant database semantics

Because of extant inconsistencies in the database, answers to queries may or may not be in accordance with the intended semantics of stored data, as encoded by integrity constraints. Also updates may or may not be in accordance with the integrity constraints. Approaches to query answering usually differ from approaches to check updates for integrity preservation, even more so if they have to cope with extant inconsistencies. We present a novel, cause-based approach that improves inconsistency-tolerant query answering and integrity checking, and provides a uniform foundation for both.

Measure-Based Inconsistency-Tolerant Maintenance of Database Integrity

To maintain integrity, constraint violations should be prevented or repaired. However, it may not be feasible to avoid inconsistency, or to repair all violations at once. Based on an abstract concept of violation measures, updates and repairs can be checked for keeping inconsistency bounded, such that integrity violations are guaranteed to never get out of control. This measure-based approach goes beyond conventional methods that are not meant to be applied in the presence of inconsistency. It also generalizes recently introduced concepts of inconsistency-tolerant integrity maintenance.

Revisiting and improving a result on integrity preservation by concurrent transactions

We revisit a well-known result on the preservation of integrity by concurrent transactions. It says that the serializability of integrity-preserving transactions yields integrity-preserving histories. We improve it in two ways. First, we discuss divergent interpretations and restate them more precisely. Second, we make it applicable in the presence of inconsistency.