Transaction.pdf

GESTION TRANSACTIONNELLE
Master II - RISR ... Adminstartion et Sécurité des Systèmes d'Information Répartis (ASSIR)
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université Dr Tahar Moulay de Saïda
Faculté de Technologie
Département d’Informatique
Master II - Réseaux Informatiques et Systèmes Répartis (RISR)
UEF32 - Administration et Sécurité des Systèmes d’Information Répartis (ASSIR)

1- Définition
Une transaction est un bloc d’instructions LMD faisant passer la
base de données d’un état cohérent à un autre état cohérent.
Exemple :
Une transaction bancaire, transfert d’argent d’un compte A vers un
compte B.
Début transaction
- Compte A : débiter de 10 000,00 DA
Solde = Solde – 10 000,00
- Compte B : créditer de 10 000,00 DA
Solde = Solde + 10 000,DA
Fin transaction

2- Caractéristiques
Une transaction assure :
 L’atomicité des instructions qui sont considérées comme une
seule opération (principe du tout ou rien) ;
 La cohérence (passage d’un état cohérent de la base à un autre
état cohérent) ;
 L’isolation des transactions entre elles (lecture consistante, …) ;
 La durabilité des opérations (les mises à jour perdurent même si
une panne se produit après la transaction).

3- Concurrence
Objectifs :
Permettre l’exécution simultanée d’un grand nombre de
transactions
Régler les conflits lecture / écriture
Garder de très bonne performance
Eviter les blocages
Exécution sérialisable
Une exécution est dite sérialisable si elle est équivalente à
une exécution sérielle :
Exécution // ou série  donne même résultat

3- Concurrence
1. Contrôle continu :
 on vérifie au fur et à mesure de l’exécution des opérations que le
critère de sérialisabilité est bien respecté.
 Méthodes pessimistes
 Idée : les conflits sont fréquents et il faut les traiter le plus tôt
possible.
2. Contrôle par certification :
 Vérifier la sérialisabilité quand la transaction s’achève.
 Approche optimiste
 On considère que les conflits sont rares et que l’on peut accepter
de ré-exécuter les quelques transactions qui posent problèmes.

3- Concurrence
 Le mécanisme première approche adoptée est le verrouillage.
 Bloquer l’accès à une donnée dès qu’elle est lue ou écrite par une
transaction.
- pose de verrou
- libération du verrou (fin de transaction par commit ou rollback)
 Poser un verrou bloque les autres transactions.
 Solution :
- Considérer deux critères :
 le degré de restriction : le niveau de la ressource à
laquelle il s’applique : tuple, page, table,
 la granularité du verrouillage
1. Le verrou partagé (« shared lock ») : permettre à plusieurs
transactions concurrentes de lire la même ressource.
2. Le verrou exclusif (« eXclusive lock ») : réserve la ressource en
écriture à la transaction qui a posé le verrou.

4- approche pessimiste : Le Verrouillage 2 phases
PRINCIPES
 verrouillage des objets en lecture/écriture
 opérations Lock(g,M) et Unlock(g)
g: granule(=attibut, tuple, table,…)
 toute transaction attend la fin des transactions
incompatibles
 garantie un graphe de précédence sans circuit
 les circuits sont transformés en verrous mortels
 une transaction ne peut relâcher de verrous avant de les
avoir tous acquis

4- approche pessimiste : Le Verrouillage 2 phases
Le terme « verrouillage à deux phases » s’explique par le fait qu’il y
a d’abord accumulation de verrous pour une transaction T, puis
libération des verrous.
Conflit :
Deux verrous V1[x] et V2[y] sont en conflit si x = y et V1 ou V2 est
un verrou en écriture.
Si une transaction T1 pose un verrou V1[x] et T2 veux poser un
verrou sur le même objet V2[x] alors la transaction T2 est mise en
attente

4- Le Verrouillage 2 phases
Problèmes du Verrouillage
Granularité des verrous
page : en cas de petits objets, trop d'objets verrouillés
objet : trop de verrous, gestion difficile
Verrou mortel
- risques de circuit d'attentes entre transactions
- Le problème des interblocages ou verrous mortels
(« deadlock »)

L’interblocages ou verrou mortel (« deadlock ») :
 Le principal défaut du verrouillage à deux phases est
d’autoriser des interblocages .
 Deux transactions concurrentes demandent chacune
un verrou sur une ressource détenue par l’autre.
Scénario :
1- T1 : V1[X] et T2 : V2[Y]
2- T1 demande le verrou de Y : V3[y] (transaction bloquée)
3- T2 demande le verrou de X : V[Y] (transaction bloquée)
T1 et T2 sont en attente l’une de l’autre : il y a interblocage.

Résolution du verrou mortel
Prévention
définir des critères de priorité de sorte à ce que le
problème ne se pose pas
exemple : priorité aux transactions les plus anciennes
Détection
gérer le graphe des attentes
lancer un algorithme de détection de circuits dès
qu’une transaction attend trop longtemps
choisir une victime qui brise le circuit

5- Ordonnancement par estampillage
Estampille (TimeStamp) associée à chaque transaction
date de lancement
garantie d'ordre total (unicité)
Conservation des estampilles
dernier écrivain Writer
plus jeune lecteur Reader
Contrôle d'ordonnancement
en écriture: estampille écrivain > Writer et > Reader
en lecture: estampille lecteur > Writer
Problèmes
reprise de transaction en cas d'accès non sérialisé
risque d'effet domino en cas de reprise de transaction

6- Verrouillage Oracle
 Pour gérer les conflits d’accès concurrents aux données, Oracle a
mis en place un système automatique de contrôle par verrouillage.
Le verrouillage est réalisé au niveau ligne.
 Un verrou exclusif est automatiquement posé sur une donnée
lorsque l’on exécute un ordre SQL SELECT... FOR UPDATE, INSERT,
UPDATE, DELETE.
 Aucune autre transaction ne peut modifier cette donnée tant
que le verrou est posé.
 La durée du verrou est celle de la transaction.
 Le verrou est relâché sur l’exécution d’un Commit ou d’un
Rollback.
Oracle détecte automatiquement les situations de
verrou mortel (deadlock). L’une des transactions
participant au deadlock est défaite par Oracle.

 Les ordres SQL de manipulation de données peuvent acquérir
des verrous à deux niveaux :
• niveau ligne (TX)
• niveau table (TM)
 Lorsqu’une transaction acquière un verrou sur la ligne qu’elle
veut modifier, elle obtient également un verrou sur la table toute
entière.
• Empêcher toute autre transaction d’exécuter un ordre
DDL (data description language) tant que le verrou n’est pas
relâché.
Les ordres DDL sont automatiquement commités.

Les verrous sur tables sont de type :
• RS (Row Share) : il est posé sur la table par une transaction qui a
posé des verrous sur des lignes dans l’intention de les modifier. Ce
verrou empêche toute autre transaction de verrouiller la table en
mode exclusif.
• S (Share) : ce verrou est posé manuellement par l’instruction LOCK
TABLE table IN SHARE MODE ;. Il empêche toute autre transaction
de modifier le contenu de la table verrouillée. Seule la transaction
qui a posé le verrou Share peut modifier le contenu de la table dans
le cas où elle est la seule à détenir ce type de verrou. Dans le cas
contraire, aucune des transactions détenant le verrou Share ne peut
modifier le contenu de la table tant que les autres n’auront pas
libérer leur verrou. Ce verrou ne garantit donc pas un accès exclusif
en écriture.

• SRX (Share Mode Exclusif) : ce verrou est posé manuellement.
Même effet que les verrous Share mais il ne peut être posé que par
une seule transaction.
• RX (Row Exclusive) : ce verrou est en général posé sur la table par
une transaction qui a réalisé une ou plusieurs mises à jour sur des
lignes de la table. Il est plus restrictif que le verrou Row Share pour
les autres transactions. Il empêche les verrouillages en mode Share
(S) et Exclusive (X)
• X (Exclusive) : ce verrou ne peut être obtenu que par une seule
transaction. Il lui confère un droit d’écriture exclusif dans la table. Il
n’autorise aux autres transactions qu’un accès en lecture. Les ordres
DDL de définition du schéma drop table et alter table posent
implicitement un verrou X sur la table.

7- Transactions réparties
OBJECTIF
Garantir que toutes les mises à jour d'une transaction
sont exécutées sur tous les sites ou qu'aucune ne l'est.
EXEMPLE
Transfert de la somme X du compte A vers le compte B
DEBUT
site 1: A = A - X
site 2: B = B + X PANNE --> INCOHERENCE DONNEES
FIN
PROBLEME
Le contrôle est réparti : chaque site peut décider de
valider ou d’annuler …

Commit en 2 Phases
Principe
Diviser la commande COMMIT en deux phases
Phase 1 :
Préparer à écrire les résultats des mises à jour dans la BD
Centralisation du contrôle
Phase 2 :
Écrire ces résultats dans la BD
Coordinateur :
Le composant système d'un site qui applique le protocole
Participant :
Le composant système d'un autre site qui participe dans
l'exécution de la transaction

Commit en 2 Phases
1. PREPARER
Le coordinateur demande aux autres sites s’ils sont prêts à
commettre leurs mises à jour.
2a. SUCCES : COMMETTRE
Tous les participants effectuent leur validation sur ordre du
client.
2b. ECHEC : ABORT
Si un participant n’est pas prêt, le coordinateur demande à tout
les autres sites de défaire la transaction.
REMARQUE
Le protocole nécessite la journalisation des mises à jour
préparées et des états des transactions dans un journal local à
chaque participant.

SITE COORDINATEUR
SITE PARTICIPANT 2
SITE PARTICIPANT 1
PREPARE PREPARE
OK OK
COMMIT COMMIT
ACK ACK
Cas Favorable

PREPARE PREPARE
OK
ACK
KO
ABORT
ABORT
ACK
SITE COORDINATEUR
SITE PARTICIPANT 2
SITE PARTICIPANT 1
Cas Défavorable

Cas Défavorable
PREPARE PREPARE
OK
ACK
OK
COMMIT
COMMIT
STATUS
COMMIT
ACK
SITE COORDINATEUR
SITE PARTICIPANT 2
SITE PARTICIPANT 1

Commit en 2 Phases
Transactions bloquées
Que faire en cas de doute ?
Demander l’état aux autres transactions : STATUS
conservation des états nécessaires message
supplémentaire
Forcer la transaction locale : ABORT
toute transaction annulée peut être ignorée
cohérence garantie avec un réseau sans perte de
message
Forcer la transaction locale : COMMIT
toute transaction commise peut être ignorée
non garantie de cohérence avec le coordinateur

Commit en 3 Phases
Inconvénient du commit
à 2 phases
en cas de time-out en
état “Prêt”, le participant
est bloqué
le commit à 3 phases
permet d’éviter les
blocages
Messages du commit à 3
phases
Prepare,
Prepare to Commit,
Global-Commit,
Global-Abort.
Initial
Wait
Abort PréCommit
Commit
CCommit/Prepare
VoteKO/GAbort VoteOK/PréCommit
PréOK/GCommit
COORDINATEUR
Initial
Ready
Abort PréCommit
Commit
Prepare/VoteOK
GAbort/Ack
PréCommit/PréOK
GCommit/Ack
PARTICIPANT

Transaction.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à Transaction.pdf

Similaire à Transaction.pdf (7)

Plus de SamirAwad14

Plus de SamirAwad14 (15)

Dernier

Dernier (15)

Transaction.pdf