130
Introduction pratique aux bases de données relationnelles
objets mémorisés dans la zone de travail sont valides, c’est-à-dire s’ils
respectent l'intégrité de la base de données.
La date du début
de la phase de
validation est
importante
Admettons pour simplifier que les phases de validation des
différentes transactions ne se chevauchent jamais. Nous relevons la
date à laquelle une transaction entre en phase de validation. Ce relevé
nous permet d’établir une liste des transactions classées par ordre
chronologique des dates de début de cette phase. Dès qu'une
transaction entre dans la phase de validation, nous vérifions si elle est
sérialisable.
Analyser les
ensembles d’objets
lus et écrits
En mode de synchronisation optimiste, la détermination de la
sérialisabilité procède comme suit : soient TRX_t la transaction à
vérifier, et TRX_1 à TRX_k les transactions qui s'exécutent en parallèle
à TRX_t et qui sont déjà validées pendant la phase de lecture de
TRX_t. Le reste n'intervient pas dans le test de sérialisabilité car toutes
les transactions sont strictement classées d'après leur date d'entrée
dans la phase de validation. En revanche, les objets lus par TRX_t
doivent être vérifiés, car dans le même intervalle de temps, ils
risquent d'avoir été modifiés par les transactions critiques TRX_1 à
TRX_k. Soient READ_SET(TRX_t) l'ensemble des objets lus par
TRX_t, et WRITE_SET(TRX_1,…,TRX_k) l'ensemble des objets
modifiés définitivenent par les autres transactions. Le critère de
sérialisabilité s'énonce comme suit :
Condition de
disjonction des
ensembles d’objets
lus et écrits
Synchronisation optimiste (optimistic concurrency control, en
anglais)
En mode de synchronisation optimiste, les ensembles
READ_SET(TRX_t) et WRITE_SET(TRX_1,…,TRX_k) doivent être
disjoints pour que la transaction TRX_t soit sérialisable.
Synchronisation
optimiste des
transactions
comptables
À titre d'exemple, considérons de nouveau les deux transactions
comptables TRX_1 et TRX_2 de la figure 4-6 en admettant que TRX_2
a été validée avant TRX_1. La transaction TRX_1 est-elle sérialisable
dans ce cas ? Avant d'y répondre, nous constatons (Figure 4-10) que
l'objet b lu par TRX_1 a été modifié par la transaction TRX_2 et
appartient à l'ensemble des objets mis à jour WRITE_SET(TRX_2).
L'intersection de WRITE_SET(TRX_2) avec l'ensemble des objets lus
Introduction pratique aux bases de données relationnelles
objets mémorisés dans la zone de travail sont valides, c’est-à-dire s’ils
respectent l'intégrité de la base de données.
La date du début
de la phase de
validation est
importante
Admettons pour simplifier que les phases de validation des
différentes transactions ne se chevauchent jamais. Nous relevons la
date à laquelle une transaction entre en phase de validation. Ce relevé
nous permet d’établir une liste des transactions classées par ordre
chronologique des dates de début de cette phase. Dès qu'une
transaction entre dans la phase de validation, nous vérifions si elle est
sérialisable.
Analyser les
ensembles d’objets
lus et écrits
En mode de synchronisation optimiste, la détermination de la
sérialisabilité procède comme suit : soient TRX_t la transaction à
vérifier, et TRX_1 à TRX_k les transactions qui s'exécutent en parallèle
à TRX_t et qui sont déjà validées pendant la phase de lecture de
TRX_t. Le reste n'intervient pas dans le test de sérialisabilité car toutes
les transactions sont strictement classées d'après leur date d'entrée
dans la phase de validation. En revanche, les objets lus par TRX_t
doivent être vérifiés, car dans le même intervalle de temps, ils
risquent d'avoir été modifiés par les transactions critiques TRX_1 à
TRX_k. Soient READ_SET(TRX_t) l'ensemble des objets lus par
TRX_t, et WRITE_SET(TRX_1,…,TRX_k) l'ensemble des objets
modifiés définitivenent par les autres transactions. Le critère de
sérialisabilité s'énonce comme suit :
Condition de
disjonction des
ensembles d’objets
lus et écrits
Synchronisation optimiste (optimistic concurrency control, en
anglais)
En mode de synchronisation optimiste, les ensembles
READ_SET(TRX_t) et WRITE_SET(TRX_1,…,TRX_k) doivent être
disjoints pour que la transaction TRX_t soit sérialisable.
Synchronisation
optimiste des
transactions
comptables
À titre d'exemple, considérons de nouveau les deux transactions
comptables TRX_1 et TRX_2 de la figure 4-6 en admettant que TRX_2
a été validée avant TRX_1. La transaction TRX_1 est-elle sérialisable
dans ce cas ? Avant d'y répondre, nous constatons (Figure 4-10) que
l'objet b lu par TRX_1 a été modifié par la transaction TRX_2 et
appartient à l'ensemble des objets mis à jour WRITE_SET(TRX_2).
L'intersection de WRITE_SET(TRX_2) avec l'ensemble des objets lus