Transactions

1
Transactions

• Witold Litwin

2
Introduction

• Beaucoup d'opérations sur une BD doivent être
  atomiques
• Transfert d'argent entre les comptes
• UPDATE Compte1
• Val Val -100
• UPDATE Compte2
• Val Val 100
• Si seulement une de ces requêtes est exécutée, la
  BD perd sa consistance

3
Transactions

• Opérations atomiques inexprimables avec une
  requête relationnelle.
• entièrement ou pas du tout
• Préservant la consistance de la BD
• comme si l'usager était isolé sur la BD
• A effet durable sur la BD, une fois terminées
  comme prévu
• Modèle ACID de transactions

4
Primitives de gestion de transactions

• BEGIN, COMMIT, ROLLBACK
• BEGIN TRANSACTION
• UPDATE Compte1
• Val Val -100
• IF SQLCODE ltgt 0 ROLLBACK EXIT
• UPDATE Compte2
• Val Val 100
• IF SQLCODE ltgt 0 ROLLBACK EXIT
• COMMIT

5
Implémentation de transactions

• TID Identificateur de transaction
• Inscription dans la BD seulement après le COMMIT
• Journalisation
• Toute opération d'une transaction est notée avant
  et après l'exécution dans un fichier journal
  présumé à l'abris de pannes
• Les opérations de commitement sont notées avant
  d'être exécutées sur la BD (write- ahead log
  protocol)
• Points de reprise (checkpoints)
• sauvegardes de l'état de la BD et notamment de
  TIDs de transactions en cours à intervalles
  réguliers

6
Et si la casse arrive...

• On ferme l'accès à la base
• On reprend le dernier checkpoint
• On retrouve sur le journal toutes les
  transactions commises après
• commencées avant ou après le checkpoint
• On reexécute chronologiquement ces transactions
• et seulement ces transactions
• On rouvre la base aux usagers

7
Transactions non-ACID

• Transactions imbriquées
• Transactions longues
• Transactions distribuées
• exigent un commitement à 2 phases (2 PC)

8
Concurrence

• Les BDs étant partagées, les transactions
  pourraient être exécutées
• l'une après l'autre
• simultanément
• meilleures performances
• possibilités d'inconsistances dans la base
• Théorie de concurrence analyse les problèmes
  d'accès simultané

9
Exemple
A 100
R2 (A)
R1 (A)
A A 200
A A 100
W1 (A)
A 200
La base
10
Exemple
A 100
R2 (A)
R1 (A)
A A 200
A A 100
W1 (A)
A 200
W2 (A)
A 300
La base
11
Gestion de la concurrence

• Verrouillage exclusif
• toute opération d'une transaction T sur une
  donnée D ne peut fait que si T obtient un verrou
  sur D
• si D est déjà verrouillé par T' quand T le
  demande, alors T est mis en attente
• Ce type de verrou est dit exclusif
• On vient de définir un protocole de gestion de
  concurrence
• Protocole 1

12
Exemple
La base
L (A)
A 100
L (A)
R1 (A)
A A 100
W1 (A)
A 200
U (A)
13
Exemple
La base
L (A)
A 100
L (A)
R1 (A)
A A 100
W1 (A)
A 200
U (A)
R2 (A)
A A 200
A 400
14
Verrouillage partagé

• les lectures ont les verrous partagés
• T et T' peuvent lire D simultanément
• les écritures doivent obtenir les verrous
  exclusifs
• si D est déjà verrouillé par T', alors T est mis
  en attente
• Avantage
• meilleures performances, mais...
• C'est la méthode la plus usité
• Protocole 2

15
Exemple
Lr (A)
A 100
Lr (A)
R1 (A)
R2 (A)
A A 100
A A 200
Lw (A)
La base
16
Exemple
Lr (A)
A 100
Lr (A)
R1 (A)
R2 (A)
A A 100
A A 200
Lw (A)
Lw (A)
La base
17
Verrou mortel

• Les transactions s'attendent mutuellement
  (deadlock)
• Solution typique
• avorter une de transactions (la victime)
• le choix est fait par le gestionnaire des verrous
  (lock manager)

18
Exemple
Lr (A)
A 100
Lr (A)
R1 (A)
R2 (A)
A A 100
A A 200
Lw (A)
Lw (A)
A
W2 (A)
A 300
La base
19
Lr (A)
A 300
R1 (A)
A A 100
Lw (A)
W1 (A)
A 400
La base
20
Les exécutions correctes

• Sérialisabilité
• Les exécutions concurrentes sont correctes ssi
  leur résultat est équivalent à celui d'une
  exécution sérielle
• Le critère naturel et le plus populaire
• débattu néanmoins pour les systèmes multibases
  distribués
• pourquoi ?

21
x x2
x 10
x ?
x x2
x x/2
22
x x2
x 10
x ?
x x2
x x/2
Exécutions sérielles équivalentes
23
Les verrous / la sérialisabilité

• Problème de "fantôme"
• existe pour les deux protocoles 1 et 2

R
T2
T1
10 20 30 40 50 60
LR(1), S S R(1), UR(1) LR(2), S S
R(2), UR(2) LR(3), S S R(3),
UR(3) .... .... LR(6), S S R(6), UR(6)
LR((3) R(3) R(3) 5, UR(3) LR((6) R(6)
R(6) - 5, UR(6)

• Le résultat de T1 ?

Temps
24
Verrouillage à 2 Phases
25
Schedules 2PL
L(a)
L(b)
L(b)
L(a)
U(a,b)
U(a)
U(b)
C
C
L(a)
L(b)
C
U(a,b)
26
L(a)
L(b)
L(b)
L(a)
L(b)
U(a,b)
U(a)
U(a)
U(b)
C
C
L(a)
U(b)
L(a)
C
L(b)
C
U(a,b)
27
Problème de "fantôme"

• Est-ce que l'exécution discutée est conforme à
  2PL ?
• Sinon comment la rendre conforme ?
• Le résultat, serait-il alors correct ?

28
Granularité de verrous

• Dans les exemples on a verrouillé des tuples
• Une table peut contenir des millions de tuples
• 2-PL peut alors conduire à la gestion de millions
  de verrous
• Est-ce la solution la plus performante ?
• Pas toujours

29
Granularité de verrous

• attribut
• tuple
• page
• table définie par un predicat
• table de base
• base de données
• impossible d'inserer/supprimer MAJ un tuple d'une
  page ou table ou base vérouillée

30
Granularité de verrous

• Granularité fine offre de concurrence
• Mais aussi plus délicats à gérer
• tables de verrous grandes
• de possibilités de verrou mortel
• En pratique en général on verrouille
• tuples
• pages
• Elargissement d'un verrou (lock escalation)
• un verrou fin est remplacé par un verrou moins
  fin
• tuple -gt table

31
Niveaux d'isolation

• Sérialisabilité totale coûte cher
• N'est pas nécessaires pour toutes transactions
• Les SGBD et SQL-3 offrent dès lors différents
  niveaux d'isolation de transactions
• à utiliser avec des précautions

32
Niveaux d'isolation
dégrée de concurrence
Les locks courts (short-term locks), latches,
sont lâchés tout-de-suite Les locks longs sont
maintenus jusqu'à la fin de la transaction
33
Read Uncommitted

• exec sql set transaction read uncommitted
• En SQL-3, une telle transaction est par défaut
  Read Only
• pour prévenir les MAJs perdues
• les Write ne sont possibles que par une
  transaction de niveau R-Committed au moins
• une telle transaction est par défaut Read Write
• sauf une déclaration Read Only dans l'ordre Set
  Transaction
• fausses valeurs de fonctions agrégat. sont
  possibles
• valeurs erronées dérivées de celles non-commises
  peuvent se propager entre les transactions

34
Read Committed

• exec sql set transaction read committed
• Seules les valeurs commises sont lues
• en utilisent R-latches de tuples
• Les écritures utilisent W-locks de tuples
• Les lectures successives d'une donnée positionnée
  par le curseur lisent toujours une même valeur
• d'où le nom cursor stability
• Un retour du curseur sur une donnée dans une même
  transaction peut par contre lire une valeur
  différente
• Il n'y a pas de MAJ perdues
• sauf si on le veut profondément
• Le calcul d'une fonction agrégat peut être erronée

35
Pas de MAJ perdue

• branch est la clé
• Le tuple '123' est verrouillé jusqu'à commit
• exec sql declare cursor d for
• select bal from acc where branch '123' for
  update of bal
• exec sql set transaction read committed
• exec sql open d
• exec sql fetch d into bal
• bal bal 5 / lang. source
• exec sql set bal bal where current of d
• exec sql close d
• exec sql commit work

36
MAJ perdue

• exec sql set transaction read committed
• exec sql select bal into bal from acc where
  branch '123'
• bal bal 5 / lang. source
• exec sql update acc set bal bal where branch
  '123'
• exec sql commit work
• Pourquoi ?

37
Read Repeatable

• exec sql set transaction read repeatable
• On utilise R-locks et W-locks de tuples
• Les lectures d'une donnée peuvent être répétées
  dans une transaction
• Une fonction agrégat peut-être correctement
  évaluée
• Pas de MAJ perdues

38
MAJ OK

• exec sql set transaction read repeatable
• exec sql select bal into bal from acc where
  branch '123'
• bal bal 5 / lang. source
• exec sql update acc set bal bal where branch
  '123'
• exec sql commit work
• Pourquoi ?

39
Read Repeatable(problème)

• Une insertion durant l'évaluation d'une fonction
  agrégat F est possible
• le tuple correspondant n'est pas verrouillé
• une deuxième évaluation de F dans une même
  transaction peut donner un résultat différent
• Ces exécutions seraient non-sérialisables
• Pourquoi ?
• Considère que chaque transaction doit lire un
  tuple avec bal_tot fait par une autre
  transaction et signaler si bal_total n'est pas le
  résultat de F
• alors on pourrait avoir une fausse alerte
• Pourquoi ?

40
Serializable

• exec sql set transaction serializable
• on utilise des verrous prédicatifs
• predicate lock
• un tel verrou s'applique à tous les tuples
  concernés par une requête
• même ceux non-existant encore
• l'anomalie de bal_tot devient impossible
• on violerait le verrous prédicatifs
• on obtient la sérialisation dans tous les cas

41
Predicate locks / Tuple lock
Le predicat
tuples verrouillées
42
Predicate locks / Tuple lock
Le predicat
tuples verrouillées
43
Predicate locks / Tuple lock
Le verrou predicatif
44
Predicate locks / Tuple lock
Le verrou predicatif
45
Serializable

• Les SGBD actuels n'offrent pas de verrous
  prédicatifs
• SQL-3 est en avance
• On peut néanmoins verrouiller toute la table
• Le cas d'anomalie citée est fort rare en pratique

46
Concurrence sous MsAccess

• Conçue pour les transactions longues
  (interactives)
• Trois modes d'accès positionnement, édit, MAJ
• ces deux dernières sont symb. par le crayon
• On utilise des loquets et des verrous (et
  estampilles)
• partagés et exclusifs
• Trois granularités
• page (n 2048 octets)
• table
• base
• Notifications
• d'une MAJ concurrente faite
• d'un verrou en écriture en cours
• Pas d'attentes, mais des relances
• Rafraîchissements

47
MsAccess

• Mode pessimiste (Edited Records)
• Le positionnement sur un tuple (la lecture) crée
  un verrous Lr de la page
• La demande d'édition signifie une demande d'un
  verrou Lw sur la page
• obtenu, sauf si un autre Lw est en cours
• alors il y a une notification (err. 3260 sous
  Access B.)
• et, si on veut, jusqu'à 10 re-essais automatiques
• "Retry Interval" est réglable entre 0 - 1000
  msec
• défaut 250 msec (les options multiusager)
• si la page a été modifiée depuis Lr
• il y a une notification (err. 3197 sous Access
  B.)
• on peut écraser la MAJ de l'autre, si on veut !

48
MsAccess mode optimiste

• Correspond au choix "No locks" dans les
  propriétés d'une forme ou les options
• L'édition correspond à Lr seulement
• donc plusieurs usagers peuvent éditer la même
  page et tuple
• la page est verrouillée en écriture seulement
  pour la MAJ (durant la "update method"), par un
  loquet
• Si un conflit alors
• la notification et les re-essais comme pour la
  méthode pessimiste (err. 3186 sous Access B.)
• Si la page a été modifiée depuis Lr par une autre
  transaction
• alors la notification d'une MAJ concurrente

49
MsAccess Lw d'une table

• Mode "All records"
• A utiliser prudemment
• L'accès est refusé si une autre transaction a un
  Lw même sur une page de la table
• cas fort probable car les insertions ne se font
  que dans la dernière page (Access 2)

50
Concurrence sous MsAcces Propriétés globales et
particularités

• Les requêtes ne tiennent pas compte de données
  non-commises (en édition)
• Les requêtes en lecture ne tiiennent pas compte
  de Lw (posés par d'autres transactions)
• particularité de MsAccess / SQL standard
• 2-PL doit être généré par l'usager
• en Access Basic
• Fantômes peuvent se créer
• Verrou mortel peut arriver
• mais pas dans les applications simples
• l'accès à un tuple à la fois par une forme typique

51
Concurrence sous MsAcces Propriétés globales et
particularités

• Il ya une possibilité de rafraîchissement d'une
  forme ouverte à la suite d'une MAJ concurrente
  (donc ouvrez l'oeil !)
• toutes les 1 32 766 sec, défaut 60 sec
• voir les options multiusager
• Les paramètres de gestion de la concurrence sont
  ceux
• par défaut ceux des options
• sauf si on a déclare un choix différent
• dans les propriétés d'une forme ou dans le
  programme Access Basic
• L'approche MsAccess mélange au niveau physique
  les verrous et les estampilles
• logiques ou peut-être physiques (voir plus loin)
• Il y a une confusion regrettable de la
  terminologie de deux approches
• les modes "optimiste" et "pessimiste"

52
MsAccessConcurrence monousager

• Mode pessimiste
• même si l'on choisit "No Locks'"
• donc pas de mode optimiste
• sans avertissement
• Mode exclusif (All Records) possible
• Aussi bien entre les formes qu'entre les tables
  et entre les formes et les tables
• Les requêtes ne tiennent pas compte de données en
  édition

53
Autres paradigmes pour gérer la concurrence

• Estampilles (timestamps)
• toute transaction est estampillée avec son temps
  t de commencement
• temps logique ou physique
• en principe, plus petit t gagne s'il y a un
  conflit
• l'autre transaction est avortée et relancée
• peut-être indéfiniment (livelock)
• Avantages/désavantages
• pas d'interblocage (deadlock)
• performances en général moins bonnes que pour le
  verrouillage

54
Autres paradigmes pour gérer la concurrence

• Deux approches
• optimiste (meilleure quand peu d'écritures)
• vérif. de conflits a posteriori à la fin de la
  transaction
• phase de certification
• si l'exec. incorrecte, alors l'une ou les deux
  transactions sont avortées
• pessimiste
• les conflits sont vérifiés tout de suite
• les avortements sont faits aussitôt

55
Sch. Pessimiste
2
2(b)
56
Sch. Pessimiste
Sch. Optimiste
1
2
2
1(a)
1(b)
2(b)
2(b)
...
A
A
4
4(a)
4(b)
C
57
Dates de valeur

• Toute transaction T est estampillée avec son
  temps-fin V (date de valeur) prévu
• en principe, le plus petit V gagne le conflit
• l'autre transaction T' est avortée et relancée ou
  mise en attente
• selon le temps de conflit / à V'
• Pas de dead-lock (pourquoi ?)
• Potentiellement efficace que estampilles
• Applications
• temps-réel (transactions avec deadlines)
• systèmes multibases
• commit implicite

58
Dates de valeur
V 6
6 (a)
59
Dates de valeur
V 6
V 8
6 (a)
8 (b)
6 (b)
A
60
Dates de valeur
V 8
8 (b)
A
Relance
V 16
16 (b)
...
C
61
Dates de valeur
V 6
6 (a)
62
Dates de valeur
V 6
V 13
6 (a)
6 (b)
13 (b)
W
...
Attente
63
Dates de valeur
V 6
V 13
6 (a)
6 (b)
13 (b)
W
...
Attente
C
C
64
COMMIT ?