Contrôle de concurrence

Dans les bases de données, plusieurs utilisateurs tentent d’accéder simultanément à la BD. Les mécanismes d’accès concurrent permettent de partager les ressources et d’améliorer les performances d’accès aux données. Le contrôle de concurrence est un mécanisme propre à SGBD, qui permet de contrôler l’exécution simultanée de transactions de manière à produire les mêmes résultats qu’une exécution séquentielle permettant ainsi d’assurer la propriété de sérialisabilité. En effet, une exécution d’un ensemble de transactions est dite sérialisable si elle donne pour chaque transaction participante, le même résultat que l’exécution en séquentiel de ces mêmes transactions. Pour garantir la propriété de sérialisabilité, plusieurs mécanismes sont utilisés :

3.1 Les estampilles

La technique des estampilles permet d’installer un ordre total entre les actions qui s’exécutent dans une base de données et ainsi de les sérialiser. Ainsi, une estampille est un numéro unique attribué à une transaction permettant de l’ordonner strictement par rapport aux autres transactions. En général, l’estampille utilisée à une transaction est son horodate de lancement concaténée avec le numéro du site sur lequel elle est lancée. Alors, l’estampille est le couple (horloge locale, numéro du site). L’inconvénient majeur des estampilles est la difficulté de synchroniser des sites de différentes horloges.

3.2 Verrouillage

L’une des techniques la plus répandue pour sérialiser les transactions est basée sur l’utilisation de verrous. Cette technique impose que l’accès aux données se fasse de manière mutuellement exclusive.

Remarque : Toute méthode de sérialisabilité basée sur le verrouillage peut donner lieu à des inter-blocages lorsque deux transactions s'entre-attendent. Pour illustrer ce cas, on peut prendre un exemple d’une transaction (T

1) qui détient un verrou en lecture ou en écriture sur la donnée (x), et une transaction (T

2) qui détient un verrou en lecture ou en écriture sur la donnée (y). La transaction (T

1) attend un verrou en

écriture sur la donnée (y)

donnée (x). Il y a dans ce cas un inter Notant aussi qu’un outil permettant l’

attentes. Les nœuds du graphe des attentes sont des transactions simultanées et les arcs orientés qui les relient représentent l'attente d'une transaction pour une

Grâce à cette représentation puisqu’il apparaît comme d

les inter-blocages impliquent différents sites insuffisant pour illustrer les inter

global.

Figure 16. Utilisation des graphes pour l’analyse des inter

Pour résoudre le problème des inter transactions concurrentes jusqu'à tard.

3.4 Protocole de validation à deux phases

Dans les systèmes répartis, un ensemble de processus collabore dans une transaction.

Afin de coordonner la décision de valider une transaction, un protocole de validation en deux étapes est généralement utilisé. Ce protocole a été proposé par Lampson en 1976. Le protocole exige un site coordinateur

et il est exécuté par chaque site. Il assure l’atomicité (sauf dans le cas de la destruction du journal log).

et seulement si toutes les transactions locales qui la composent sont valides aussi. En et la transaction (T

2) attend un verrou en écriture sur la . Il y a dans ce cas un inter-blocage.

permettant l’analyse des inter-blocages est le graphe des du graphe des attentes sont des transactions simultanées et les arcs orientés qui les relient représentent l'attente d'une transaction pour une

Grâce à cette représentation de graphe, il est facile de localiser

comme des cycles sur le graphe. Dans un environnement réparti, blocages impliquent différents sites, ainsi seul le graphe des attente

pour illustrer les inter-blocages, il faut également un graphe

. Utilisation des graphes pour l’analyse des inter-blocages

Pour résoudre le problème des inter-blocages, la solution consiste à

transactions concurrentes jusqu'à la suppression de cycles et de les reprendre plus

Protocole de validation à deux phases

Dans les systèmes répartis, un ensemble de processus collabore dans une transaction.

Afin de coordonner la décision de valider une transaction, un protocole de validation en deux étapes est généralement utilisé. Ce protocole a été proposé par Lampson en Le protocole exige un site coordinateur pour contrôler et des sites participants et il est exécuté par chaque site. Il assure l’atomicité (sauf dans le cas de la destruction du journal log). Dans ce protocole, une transaction globale est validée si et seulement si toutes les transactions locales qui la composent sont valides aussi. En ttend un verrou en écriture sur la

blocages est le graphe des du graphe des attentes sont des transactions simultanées et les arcs orientés qui les relient représentent l'attente d'une transaction pour une autre.

les inter-blocages es cycles sur le graphe. Dans un environnement réparti, raphe des attentes local est un graphe au niveau

blocages

consiste à annuler des suppression de cycles et de les reprendre plus

Dans les systèmes répartis, un ensemble de processus collabore dans une transaction.

Afin de coordonner la décision de valider une transaction, un protocole de validation en deux étapes est généralement utilisé. Ce protocole a été proposé par Lampson en et des sites participants, et il est exécuté par chaque site. Il assure l’atomicité (sauf dans le cas de la ne transaction globale est validée si et seulement si toutes les transactions locales qui la composent sont valides aussi. En

Support de cours Bases de Données Distribuées

effet, si au moins une transaction locale ne valide pas, toutes les transactions sont annulées. Il se compose de deux phases :

− Phase de préparation : dans cette phase, le coordinateur demande à chaque participant de se préparer pour valider la transaction locale.

− Phase de validation : dans cette phase, le coordinateur ordonne à tous les participants de valider ou d’annuler leur transaction. La décision est prise par le coordinateur en tenant compte de la réponse de chaque participant.

Les transactions distribuées présentent deux avantages : (i) les données situées sur d’autres serveurs, peuvent être mises à jour et les instructions UPDATE peuvent être gérées comme étant une seule unité. (ii) utilisation du 2-PC transparente à l’utilisateur.

Figure 17. Exemples du protocole de validation en deux étapes