bdddddddddddddd

(A)tomicité : Une transaction doit effectuer toutes ses mises à
jour ou ne rien faire du tout
(C)ohérence : Une transaction doit faire passer la base de
données d’un état cohérent à un autre état cohérent
(I)solation : Les résultats d’une transaction ne doivent être
visibles aux autres transactions qu’une fois validée
(D)urabilité : Le système doit garantir que les modifications
apportées par une transaction sont conservées en cas de panne

Granule : Un granule de concurrence est l’unité de données
contrôlée par le SGBD (il s’agit, par exemple, d’un tuple ou
d’une table).

Action : Une action est l’unité indivisible exécutée par le
SGBD sur un granule. Il s’agit généralement d’une lecture ou
d’une écriture.

Exécution de transactions : Exécution d’actions obtenues en
intercalant les actions des transactions tout en respectant
l’ordre interne de chaque transaction.

Opérations permutables : Oi et Oj sont deux opérations
permutables si le résultat de l’exécution de Oi suivi de Oj est le
même que celui de Oj suivi de Oi.

Succession : Une succession est une exécution successive de
transactions (sans simultanéité entre transactions).

Exécution sérialisable : Une exécution sérialisable est une
exécution de transactions donnant le même résultat qu’une
succession de transactions.

Précédence : On dit qu’une transaction Ti précède Tj si : Ti
accomplit une opération Oi avant la transaction Tj qui veut
accomplir une opération Oj sur un même granule où Oi et Oj sont
en conflits : lecture puis écriture, écriture puis lecture ou écriture
puis écriture.

Graphe de précédence : Graphe dont les noeuds sont des
transactions et un arc de Ti vers Tj signifie que Ti précède Tj dans
l’exécution d’une opération concernant le même granule.
Une condition pour qu’une exécution de transactions soit
sérialisable : le graphe de précédence est sans circuit.

Pour pallier aux problèmes de pertes de mise à jour provoquées par
l’annulation d’une transaction (exemple 1), le protocole PXE étend
PX dans le sens où les verrous sont maintenus jusqu’à la fin de la
transaction.

Si une transaction possède un verrou partagé sur un granule alors
une autre transaction peut acquérir un verrou partagé sur ce granule
mais aucune transaction ne peut acquérir un verrou exclusif sur le
même granule jusqu’à ce que les verrous partagés soient libérés.
L’acquisition d’un verrou partagé est réalisée par la commande
SFIND.

Toute transaction qui veut mettre à jour un granule doit exécuter la
commande SFIND pour obtenir un verrou partagé.
Toute tentative de mise à jour de ce granule (par l’opération
UPDATE) transforme le verrou partagé en verrou exclusif et
provoque sa mise à jour.
Les systèmes supportant le protocole PS montrent qu’il se produit
de nombreux interblocages.

Le protocole PSE étend le protocole PS dans le sens où les verrous
sont libérés à la fin de la transaction (idem que PXE pour PX).

Pour résoudre le problème d’interblocage il suffit de choisir une
transaction victime pour laquelle on doit annuler les actions
effectuées par cette transaction (ROLLBACK). Le choix de cette
transaction peut se faire selon différents critères : la plus récente,
ou celle qui mobilise le plus petit nombre de verrous etc.
Concernant la transaction annulée, plusieurs solutions : on peut
décider de la redémarrer immédiatement après avoir fait disparaître
le circuit du graphe ou après avoir laissé s’écouler un certain laps de
temps.

  X S		X : Verrou exclusif
X N N		S : Verrou partagé
S N O		N : Demande non satisfaite
		O : Demande accordée

Un verrou de mise à jour donne une indication sur l’intention de
mise à jour d’un granule par une transaction.
Ce type de verrou est incompatible avec des verrous de mise à jour
et des verrous exclusifs mais reste compatible avec des verrous
partagés.
Ce type de verrou permet d’éviter des situations d’interblocage.

Toute transaction qui souhaite mettre à jour un granule doit
exécuter la commande UFIND pour obtenir un verrou. Toute mise
à jour du granule transforme le verrou en verrou exclusif.

Le protocole PUE étend PU comme c’était le cas pour les
protocoles précédents en conservant les verrous exclusifs jusqu’à la
fin de la transaction.

  X U S
X N N N		X : Verrou exclusif S : Verrou partagé U : Mise à jour
U N N O		N : Demande non satisfaite
S N O O		O : Demande accordée

Le verrouillage à deux phases consiste à verrouiller les granules au
fur et à mesure des accès par une transaction et à relacher les
verrous seulement après obtention de tous les verrous.

Deux règles à respecter :
Règle 1 : avant de lire ou mettre à jour un granule, la
transaction doit obtenir un verrou sur ce granule
Règle 2 : après la libération du verrou, la transaction ne peut
plus acquérir aucun verrou.
Si toutes les transactions obéissent aux deux règles, alors toute
exécution imbriquée de ces transactions est sérialisable.

Wait-Die : Il garantit que les transactions en attente attendent des
transactions plus jeunes :
Lorsqu’une transaction A demande un verrou déjà verrouillé par une
autre transaction B alors A attend si elle est plus vieille que B,
autrement A est annulée et redémarrée

Wound-Wait : Il garantit que les transactions en attente attendent des
transactions plus vieilles :
Lorsqu’une transaction A demande un verrou déjà verrouillé par une
autre transaction B alors A attend si elle est plus jeune que B,
autrement B est annulée et redémarrée

Read Uncommited : Ce mode d’isolation correspond à l’absence du contrôle de
concurrence entre transactions. Dans ce mode, il est possible de
rencontrer des lectures sales, des lectures non répétables ou des
tuples fantômes.

Read Commited :
Ce mode d’isolation est adopté par défaut dans ORACLE. Il
empêche la lecture des tuples qui ne sont pas encore validés. Ce
mode n’empêche pas des lectures non répétables ou des tuples
fantômes.

Repeatable Read : Ce mode d’isolation est adopté par défaut dans MYSQL.
Il garantit que l’exécution successive d’une requête dans une
transaction retourne le même résultat qu’au début de la transaction.
Il empêche la lecture des tuples qui ne sont pas encore validés.
Il n’empêche pas la création de tuples fantômes.

Serializable : Ce mode d’isolation est total. Il retourne un résultat équivalent à
une exécution séquentielle des transactions. Cette garantie se fait
au prix d’un blocage élevé entre les transactions.

ROW SHARE (RS) : accès simultané à la table en vue de
modifier ces lignes et en interdisant de verrouiller la table en
exclusif (X)
ROW EXCLUSIVE (RX) : similaire à RS mais en interdisant
tout accès partagé (S) ou exclusif (X ou SRX) sur la table. Ce
mode est positionné automatiquement dans les cas suivants :
updating, inserting, or deleting sur la table
SHARE (S) : accès interdit en mode exclusive (RX, SRX, X) à
la table. Il autorise des verrous partagés (RS ou S) en
interdisant aux transactions des opérations de mise à jour
SHARE ROW EXCLUSIVE (SRX) : il pose un verrou exclusif
sur la table en partageant ses lignes avec les autres
transactions.
EXCLUSIVE (X) : il pose un verrou exclusif sur la table en
interdisant aux autres transactions toutes les opérations de
mise à jour des lignes de la table


   RS RX S SRX X
RS O  O  O  O  N
RX O  O  N  N  N
S  O  N  O  N  N
SRXO  N  N  N  N
X  N  N  N  N  N


SET TRANSACTION ISOLATION LEVEL <option>
SET TRANSACTION READ ONLY
Deux possibilités pour placer des verrous explicites sous Oracle avec:
l’instruction select avec l’option For Update : select from
employe where nuempl=20 for update
l’instruction lock : LOCK TABLE nom-table IN mode-verrou
MODE [NOWAIT]