Les transactions

1
Les transactions

• Une séquence dactions sexécutant comme un
  ensemble.
• Agit sur des objets d une BD
• Attributs, enregistrements, pages, fichiers,
• Les transactions ont comme objectif de
• Permettre une exécution concurrent des requêtes
  et des m-à-j.
• garantissent qu elle ne sont pas perdues
• Deux aspects dans les implantations de
  transactions
• Contrôle de la concurrence
• Gestion des pannes

2
Séquences de transactions

• Deux séquences de transactions sont sérialisables
  si elles sont équivalentes à une exécution
  séquentielle des transactions.

T2 read(X) read(Y)
T1 write(X) write(Y)

• write(X)
• write(Y)
• read(X)
• read(Y)

Seq. Equiv.

• write(X)
• read(X)
• write(Y)
• read(Y)

Une exécution
Seq. non. Equiv.

• write(X)
• read(X)
• read(Y)
• write(Y)

Begin read BAL Ajouter 10 write BAL Commit
Begin read BAL Soustraire 30 write
BAL Commit
Bal 100
Bal 100
Bal 110
Bal 70
3
Accès concurrentiel aux BD

• On doit contrôler l'accès concurrentiel aux BD
  pour préserver sa cohérence.
• On utilise une sémantique d'entrelacement des
  actions (interleaving). Ce qui peut provoquer des
  résultats différents.

T1 read(X) XX-100 read(Y) YY100

• T2
• read(X)
• XX30

• read(X)
• XX-100
• read(Y)
• YY100
• read(X)
• XX30

• read(X)
• XX30
• read(X)
• XX-100
• read(Y)
• YY100

read(X) XX-100 read(X) XX30 read(Y) YY10
0

• read(X)
• XX-100
• read(X)
• XX30
• read(Y)
• YY100

4
Exécution de transactions
Begin action action action
action Commit
Begin action action action Rollback
Begin action action action Rollback
Echec !
Succès
Échec
5
Exécution des transactions

• Une transaction peut terminer de deux façons
• Engagée (commit) Son effet devient visible aux
  autres transactions.
• Avortée (abort) Toutes ses mises à jour doivent
  être défaites.

6
États d une transaction
Read Write
Commit
End transaction
Partiellement engagée
Début
Active
Engagée
Abort
Abort
Avortée
7
La technique de verrouillage

• On utilise deux types de verrous
• S partageable (Shared) . Utilisé lors de la
  lecture.
• X eXclusif. Utilisé lors de l'écriture.
• Une application obtient le verrou sur un objet
  (Attribut, ligne, table,...) en fonction de la
  disponibilité de celui-ci.
• Les verrous doivent respecter des conditions de
  compatibilité

- X S - X Non Non Oui S Non Oui Oui - Oui Oui OUI
8
Concurrence et verrous
Perte de mise à jour
Lectures impropres
Lectures impropres
UPDATE R (!X/R) ROLLBACK (Libère X/R)
FETCH R (!S/R) UPDATE R (?X/R)
Attente
FETCH R (!S/R) R3 (?X/R) Attente
.
FETCH R (?S/R) Attente Attente
Attente (!S/R)
UPDATE R (!X/R) ROLLBACK (Libère X/R)
UPDATE R (?X/R) Attente Attente
Attente (!X/R)
!S/R (!X/R) obtient un verrou S (X) sur R ?S/R
(?X/R) demande un verrou S (X) sur R
9
La technique du timestamp

• Le SGBD génère une l'heurodate (timestamp) pour
  ordonner les transactions (TS(T)).
• Si deux transactions veulent accéder au même
  item, alors la transaction avec le plus petit TS
  est exécutée en premier.
• Deux types d heurodates
• read_TS(X) Plus haut TS des transactions qui ont
  lus X.
• write_TS(X) Plus haut TS des transactions qui
  ont écrits X.

10
La technique d estampillage

• Si une transaction T veut exécuter write_item(X)
• Si read_TS(X) gt TS(T), alors on défait la
  transaction T une autre transaction plus
  récente que T a déjà lu X.
• Si write_TS(X) gt TS(T), alors on n'exécute pas
  l'opération d'écriture pour ne pas perdre
  l'écriture précédente de X.
• Sinon, on exécute l'écriture et write_TS(X)
  TS(T)
• Si une transaction veut exécuter read_item(X)
• Si write_TS(X) gt TS(T), alors on défait T et on
  refuse l'opération d'écriture une transaction
  plus récente que T a déjà écrit X.
• Si write_TS(X) lt TS(T), alors on exécute
  l'opération de lecture de T et read_TS(X) max
  (TS(T) , read_TS(X))

11
Les technique optimiste

• Aucun contrôle à priori n'est fait sur les
  transactions
• Toutes le mises à jour sont faites sur des copies
  des items.
• A la fin de chaque transaction on vérifie si une
  transaction a violé la condition de
  sérialisation. Sinon la mise à jour sont faites
  sur la BD.

12
Propriétés des transactions

• Principe ACID
• Atomicity exécution selon le principe du
  tout-ou-rien.
• Consistency l exécution garde la cohérence des
  données de la BD
• Isolation les mises à jours d une transaction
  n ont pas d effets visibles avant sa fin.
• Durability l effet d une transaction doit
  être durable. Même après une panne.

13
Atomicité

• Atomicité et RPC
• at least once essayer jusqu à réception du ack
• at most once essayer une fois.
• exactly once essayer jusquà la réception du ack
  et éliminer les répétitions.
• Si la transaction implique
• Insérer plusieurs enregistrements
• Envoyer plusieurs messages
• Alors on a besoin du Tout ou rien 

14
Cohérence

• Cohérence avant et après lexécution de la
  transaction.
• Begin - Commit détermine le début et la fin
  d une transaction.
• On peut ne pas respecter la cohérence pendant le
  déroulement de la transaction
• Débit sans crédit
• Détruire un vieux fichier avant de créer sa
  copie

Nouvel état en construction
Begin
Commit
15
Isolation

• Les programmes qui s exécutent concurremment
  sur les mêmes données peuvent créer des
  anomalies.
• Le système devrait gérer l accès pour nous.
• Le système protège les applications ( Verrous,
  Versions de BD,).

Begin read BAL add 10 write BAL Commit
Begin read BAL Subtract 30 write BAL Commit
Bal 100
Bal 100
Bal 110
Bal 70
16
Durabilité

• Quand une transaction set termine on veut
  qu elle dure même après une panne.
• On doit avoir des moyens de défaire les
  transactions dont les actions (temporaires) sont
  perdues en cas de panne.
• Besoin des journaux continus

17
Implantation de ACID

• Atomicité
• On utilise des opérations DO/UNDO/REDO
• Idempotence
• Le protocole TPC (Two-Phase Commit)
• Durabilité
• On utilise des journaux (sur supports) durables.
• Forcer les opération de mise-à-jour au commit
• Isolation
• Verrous (locks) ,..

18
Les protocoles DO/UNDO/REDO

• Chaque action génère un enregistrement dans le
  log.
• UNDO défait une transaction.
• REDO refait une transaction.

Ancien état
Nouvel état
DO
Log
Log
Ancien état
Nouvel état
UNDO
Log
Ancien état
Nouvel état
REDO
19
Contenu dun enregistrement Log
T0, begin T0,X,99,100 T1,begin T1,Y,199,200 T2,beg
in T2,Z,51,300 T1,M,1000,123 T1,commit T3,begin T2
, abort T3,Y,200,50 T4,begin T4,M,10,100 T3,commit

• Plusieurs formats existent pour les
  enregistrements du Log. En voici une
• Id. de transaction, begin (pour les trans.
  amorcées)
• Id. de transaction, commit (pour les trans.
  engagées)
• Id. de transaction, abort
• Id. de transaction, Item, Ancien, Nouveau
• Chaque action de la transaction ajoute un
  enregistrement dans le Log.

Log
20
Défaire une transaction

• Lire le log à l envers.
• Défaire (UNDO) une action à la fois.

Log
Log
Ancien état
Nouvel état
UNDO
Ancien état
Nouvel état
UNDO
21
Durabilité

• Lorsqu une action est engagée (COMMIT), on met
  son Log dans un disque durable (protégé,
  dupliqué,...).
• On a besoin du log pour refaire ces transactions
  en cas de panne
• Perte de données sur mémoire tampon
• Panne de disque
• Le transaction devient alors durable.

Log
Log
Log
22
Restauration après panne

• En cas de panne,
• Refaire (REDO) le log de toutes les transactions
  engagées (i.e. celles qui ont une entrée avec
  COMMIT dans le Log)
• Ensuite défaire (UNDO) touts les transactions non
  engagées (i.e. celles qui n ont pas dentrée
  avec COMMIT dans le Log)
• Le système vide les contenus des buffers vers la
  BD lors de l établissement de point de reprise
  (checkpoints).

23
Mécanisme de reprise

• Lors d une panne système (ex. coupure de
  courant) , on se base sur les points
  de reprise.

Point de reprise (Checkpoint)
Point de panne
T1
T2
T3
T4
T5
T3 et T5 doivent être défaites. T2 et T4 doivent
être refaites T1 est permanente.
24
Le protocole TPC

• Dans le cas où l on doit mette à jour plusieurs
  logs (BD répartie, application distribuée), on
  doit avoir un mécanisme de coordination des
  engagements
• Two-Phase Commit
• Deux phases
• 1. Vote Pouvez-vous vous engager ?
• 2. Si tous les participants votent oui, on
  s engage !
• Les transactions dans ce cas sont gérées par un
  coordinateur spécialisé Transaction Manager (TM)

25
Transactions réparties

• Une transaction répartie implique plusieurs
  sites.
• Un client demande le transfert d'argent entre
  deux de ses comptes
• Un client demande le transfert d'argent entre
  comptes dans des banques différentes.
• On a deux types de transactions réparties

T11
Transactions simples
Site X
T1
Site Client
T21
Site Client
Site Y
T2
T22
Transactions imbriquées
Site Z
26
Transactions imbriquées

• Utilisées lorsqu une transaction nécessite la
  collaboration de plusieurs sites

Retrait(A,1000)
Retrait(B,2000)
T
Client
Dépôt(C,1000) Dépôt(D,2000)
27
Coordination des transactions

• Les transactions distribuées utilisent le service
  d'un coordinateur (TM). Celui-ci peut être
• le premier serveur contacté pour la transaction
• un moniteur de transactionnel dédié (Tuxedo, )

Coordinateur
1. X.OpenTransction 2. X.Retrait(A,1000) 8.
X.CloseTransaction(T)
Transaction T OpenTransaction
X.Retrait(A,1000) Z.Dépôt(C,1000)
Y.Retrait(B,2000) Z.Dépôt(D,2000)
CloseTransaction(T)
X
5. Y.AddServer(T,X) 6. Y.Retrait(B,2000)
Y
Client
3. Z.AddServer(T,X) 4. Z.Dépôt(C,1000) 7.
Z.Dépôt(D,2000)
Z
28
Le moniteur de transactions
Le moniteur de transactions (TM) gère les
transactions. Il donne les identificateurs de
transactions à chaque Begin. Tout sous-système
qui participe dans la transaction est géré par
une moniteur de ressources (RM). Lors des
ROLLBACK, le TM appelle les ROLLBACK de tous les
RM.
RM
RM
RM
RM
Join
RM
RM
Join
TM
TM
TM
Begin
App
App
App
29
Le protocole TPC

• Le protocole gère l exécution des transactions
• Coordonne le COMMIT et le ROLLBACK

TM
RM
RM
TM
RM
RM
TM
RM
RM
PREPARE
PREPARE
PREPARE
PREPARE
PREPARE
PREPARE
OK
OK
NO
NO
OK
OK
COMMIT
COMMIT
ABORT
COMMIT
ABORT
COMMIT
ACK
ACK
ACK
STATUS
ACK
ACK
COMMIT
ACK
30
Exemple de Transaction en SQL

• Les informations du client
• Écrire les informations de réservation
• Écrire les modifications
• SELECT customer_id, customer_lname,
  customer_fname
• INTO v_customer_id, v_customer_lname,
  v_customer_fname
• FROM customer WHERE customer_id v_input_cid
  
• UPDATE flight_reservations
• SET seat_assignment v_customer_id
• WHERE airline 'ACME' AND flight_number 123
• AND departure_date '05-JAN-2000' AND
  departure_city 'Newark'
• INSERT INTO credit_card_charges
• VALUES (sysdatetime, v_customer_id,
  v_customer_lname, v_customer_fname,
  'VERSA', credit_card_number, exp_date)

31
Exemple de transactions dans Oracle

• CREATE PROCEDURE bookflight
• ( v_input_cid IN VARCHAR(20) ) IS
• v_customer_id VARCHAR(30)
• v_customer_lname VARCHAR(40)
• v_customer_fname VARCHAR(30)
• credit_card_number VARCHAR(30)
• exp_date DATE
• BEGIN
• SET TRANSACTION SERIALIZABLE
• SELECT customer_id, customer_lname,
  customer_fname
• INTO v_customer_id, v_customer_lname,
  v_customer_fname
• FROM customer WHERE customer_id
  v_input_cid
• UPDATE flight_reservations
• SET seat_assignment v_customer_id
• WHERE airline 'ACME' AND flight_number 123
• AND departure_date '05-JAN-2000'
• AND departure_city 'Newark'

32
Exemple de transactions dans Oracle

• INSERT INTO credit_card_charges
• VALUES (sysdatetime, v_customer_id,
  v_customer_lname,
• v_customer_fname, 'VERSA',
  credit_card_number,
• exp_date)
• COMMIT
• EXCEPTION
• WHEN OTHERS THEN
• BEGIN
• ROLLBACK
• END
• END

33
ESQL et les transactions

• EXEC SQL DECLARE Z CURSOR FOR
• SELECT F, NOM, CA, VILLE FROM F
• WHERE EXISTS ( SELECT FROM FP WHERE FP.F
  F.F
• AND FP.P P_donne)
• FOR UPDATE OF CA
• Read(P_donné, Ville_donnée, Augmentation,Niveau)
  
• EXEC SQL OPEN Z
• if SQLCODE ltgt 0 then goto erreur
• Encore true
• While Encore do
• begin
• EXEC SQL FETCH Z INTO F, Nom,CA,Ville
• if SQLCODE 100 then ENCORE false
• else if SQLCODE ! 0 then goto erreur
• else begin

34
ESQL et les transactions

• DISP " "
• if Ville Ville_donnée then
• begin
• EXEC SQL UPDATE F
• SET CA CA Augmentation where CURRENT OF Z
  
• if SQLCODE ltgt 0 then goto erreur
• DISP "m-a-j OK"
• end
• else if CA lt Niveau then
• begin
• EXEC SQL DELETE FROM FP WHERE F F
• if SQLCODE ltgt 0 SQLCODE ltgt 100 then
  goto erreur
• EXEC SQL DELETE FROM F WHERE CURRENT OF
  Z
• if SQLCODE ltgt 0 then goto erreur
  

35
ESQL et les transactions

• if SQLCODE ltgt 0 then goto erreur
• DISP "Destruction OK "
• end
• print(F,Nom,CA,Ville,DISP)
• end
• end
• EXEC SQL CLOSE Z
• EXEC SQL COMMIT
• STOP
• erreur begin
• print ("CODE ERREUR EST ", SQLCODE)
• EXEC SQL ROLLBACK
• STOP
• end