Isolation (informatique)

Résumé

Dans les systèmes de gestion de base de données (SGBD), l'isolation est la capacité d'un système d'isoler les modifications dans une transaction en cours de celles faites dans les autres transactions conduites simultanément, jusqu'à ce qu'elle soit complétée. C'est l'une des quatre propriétés ACID d'une base de données. Contrôle de concurrence L'isolation des transactions d'une base données est assurée par son moteur de stockage, par un contrôle de concurrence entre elles. Le système le plus commun de contrôle de concurrence est le verrouillage à deux phases, ou 2PL (dans l'anglais two-phase locking), qui est composé de deux phases consécutives : la pose de verrous et leurs retraits. Problèmes d'isolation Une mauvaise isolation des transactions peut essentiellement causer quatre problèmes :

Lecture fantôme : les données recherchées par une transaction selon une condition diffèrent entre deux recherches (à la suite de leurs mises à jour par d'autres transac

Source officielle

https://fr.wikipedia.org/wiki/Isolation_(informatique)

À propos de ce résultat

Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.

Publications associées (6)

Publications associées

Chargement

Personnes associées (2)

Personnes associées

Chargement

Unités associées (1)

Unités associées

Chargement

Concepts associés (13)

Concepts associés

Chargement

Cours associés (7)

Cours associés

Chargement

Séances de cours associées (28)

Séances de cours associées

Chargement

Robustness Against Read Committed: A Free Transactional Lunch

Bas Ketsman, Christoph Koch

Transaction processing is a central part of most database applications. While serializability remains the gold standard for desirable transactional semantics, many database systems offer improved transaction throughput at the expense of introducing potential anomalies through the choice of a lower isolation level. Transactions are often not arbitrary but are constrained by a set of transaction programs defined at the application level (as is the case for TPC-C for instance), implying that not every potential anomaly can effectively be realized. The question central to this paper is the following: when - within the context of specific transaction programs - do isolation levels weaker than serializability, provide the same guarantees as serializability? We refer to the latter as the robustness problem. This paper surveys recent results on robustness testing against (multiversion) read committed focusing on complete rather than sufficient conditions. We show how to lift robustness testing to transaction templates as well as to programs to increase practical applicability. We discuss open questions and highlight promising directions for future research.

ASSOC COMPUTING MACHINERY2022

Chargement

Deciding Robustness for Lower SQL Isolation Levels

Bas Ketsman, Christoph Koch

While serializability always guarantees application correctness, lower isolation levels can be chosen to improve transaction throughput at the risk of introducing certain anomalies. A set of transactions is robust against a given isolation level if every possible interleaving of the transactions under the specified isolation level is serializable. Robustness therefore always guarantees application correctness with the performance benefit of the lower isolation level. While the robustness problem has received considerable attention in the literature, only sufficient conditions have been obtained. The most notable exception is the seminal work by Fekete where he obtained a characterization for deciding robustness against SNAPSHOT ISOLATION. In this paper, we address the robustness problem for the lower SQL isolation levels READ UNCOMMITTED and READ COMMITTED which are defined in terms of the forbidden dirty write and dirty read patterns. The first main contribution of this paper is that we characterize robustness against both isolation levels in terms of the absence of counter example schedules of a specific form (split and multi-split schedules) and by the absence of cycles in interference graphs that satisfy various properties. A critical difference with Fekete's work, is that the properties of cycles obtained in this paper have to take the relative ordering of operations within transactions into account as READ UNCOMMITTED and READ COMMITTED do not satisfy the atomic visibility requirement. A particular consequence is that the latter renders the robustness problem against READ COMMITTED coNP-complete. The second main contribution of this paper is the coNP-hardness proof. For READ UNCOMMITTED, we obtain LOGSPACE-completeness.

ASSOC COMPUTING MACHINERY2020

Chargement

The isolation level Multiversion Read Committed (RC), offered by many database systems, is known to trade consistency for increased transaction throughput. Sometimes, transaction workloads can be safely executed under RC obtaining the perfect isolation of serializability at the lower cost of RC. To identify such cases, we introduce an expressive model of transaction programs to better reason about the serializability of transactional workloads. We develop tractable algorithms to decide whether any possible schedule of a workload executed under RC is serializable (referred to as the robustness problem). Our approach yields robust subsets that are larger than those identified by previous methods. We provide experimental evidence that workloads that are robust against RC can be evaluated faster under RC compared to stronger isolation levels. We discuss techniques for making workloads robust against RC by promoting selective read operations to updates. Depending on the scenario, the performance improvements can be considerable. Robustness testing and safely executing transactions under the lower isolation level RC can therefore provide a direct way to increase transaction throughput without changing DBMS internals.

ASSOC COMPUTING MACHINERY2021

Chargement