Transcript GESTION DE TRANSACTIONS CONCURRENTES

Gestion des transactions


1. Le mode transactionnel
2. Les accès concurrents






3.Gestion de transactions





2.1 Objectifs
2.2 Les bases
2.3 Le verrouillage à deux phases
2.4 L'ordonnancement par estampilles
2.5 Techniques avancées et modèles étendues
3.1. Journaux et reprise
3.2. Scénarios de reprise
3.3. Journalisation et modèles étendus
3.4. Cas des systèmes répartis
4. Moniteurs transactionnels
‹#›
 D'après G. Gardarin
1. Le mode transactionnel (OLTP)

Opérations typiques
 Mises à jour ponctuelles de tuples à partir de vues
prédéfinies, souvent répétitive, sur les données les plus
récentes

Exemple
 Benchmark TPC-A et TPC-B : débit / crédit sur une base de
données bancaire


TPC-A benchmark en mode transactionnel,
TPC-B benchmark en mode traitement par lot.
 Mesure le nombre de transactions par seconde (tps) et le
coût par tps.
‹#›
 D'après G. Gardarin
La base des modes TPC-A/TPC-B
1
100000
Agences
Caissiers
Comptes
Historique
100
Taille pour 10 terminaux, avec règle d'échelle ( scaling rule)
‹#›
 D'après G. Gardarin
La transaction débit - crédit

Begin-Transaction
 Update Account Set Balance = Balance + Delta
// Montant Delta
Where AccountId = Aid ;
 Insert into History (Aid, Tid, Bid, Delta, TimeStamp)
 Update Teller Set Balance = Balance + Delta
Where TellerId = Tid ;
 Update Branch Set Balance = Balance + Delta
Where TellerId = Tid ;



End-Transaction.
Objectif : temps de réponse de 90 % des transactions < 2 s
Chaque terminal génère une transaction toute les 10s
 Performance = Nombre de transactions commises /Temps exécution moyen
 Temps exécution moyen =Ellapse time
‹#›
 D'après G. Gardarin
Cohabitation avec le mode décisionnel


Les transactions doivent souvent cohabiter avec des
requêtes décisionnelles, et traiter un grand nombre de
tuples en lecture.
Exemple :
 Moyenne des avoirs des comptes par agence
 SELECT B.BranchId, AVG(C.Balance)
FROM Branch B, Account C
WHERE B.BranchId = C.BranchId
GROUP BY B.BranchId ;
‹#›
 D'après G. Gardarin
Les risques de disfonctionnement

Problèmes de la gestion des accès concurrents
 Pertes d'opérations.
 Introduction d'incohérences.
 Verrous mortels (deadlock).

Panne de transaction
 Erreur en cours d'exécution du programme applicatif.
 Nécessité de défaire les mises à jour effectuées quand elles conduisent à
des incohérences.

Panne système
 Reprise avec perte du contenu de la mémoire centrale : toutes les
transactions en cours doivent être défaites.

Panne disque
 Perte de la base, d'où sauvegardes!
‹#›
 D'après G. Gardarin
Propriétés fondamentales des transactions

Transaction
 Séquence d'opérations liées comportant des mises à jour ponctuelles
d'une base de données devant vérifier les propriétés ACID.

Atomicité
 Unité de cohérence : toutes les mises à jour doivent être effectuées ou
aucune.

Cohérence
 La transaction doit faire évoluer la base de donnée d'un état cohérent à
un autre.

Isolation
 Les résultats d'une transaction ne sont visibles aux autres transactions
qu'une fois la transaction validée.

Durabilité
 Les modifications d'une transaction validée ne seront jamais perdue
‹#›
 D'après G. Gardarin
Opérations Commit et Abort

Introduction d'actions atomiques
 Commit (terminaison avec succès) et Abort (terminaison
avec échec).
 Ces actions s'effectuent en fin de transaction.

Commit
 Validation de la transaction.
 Rend effectives toutes les mises à jour de la transaction.

Abort
 Annulation de la transaction.
 Défait toutes les mises à jour de la transaction.
‹#›
 D'après G. Gardarin
Schéma d'une transaction simple


Fin avec succès ou échec
Begin_Transaction
 update
 update

.....
 Commit ou Abort
- Provoque l'intégration réelle des mises
à jour dans la base
- Relâche les verrous
- Provoque l'annulation des mises à jour
- Relâche les verrous
- Reprend la transaction
‹#›
 D'après G. Gardarin
Effet logique
Mémoire de la
transaction
Update
Update
Commit
Bases de données
‹#›
Abort
Poubelle
 D'après G. Gardarin
Interface applicative

API pour transaction simple
 Trid Begin (context*)
 Commit ()
 Abort()

Possibilité de points de sauvegarde :
 Savepoint Save()
 Rollback (savepoint) // savepoint = 0 ==> Abort

Quelques interfaces supplémentaires
 ChainWork (context*) // Commit + Begin
 Trid Mytrid()
 Status(Trid) // Active, Aborting, Committing, Aborted,
Committed
‹#›
 D'après G. Gardarin
2. Les accès concurrents





‹#›
2.1 Objectifs
2.2 Les bases
2.3 Le verrouillage à deux phases
2.4 L'ordonnancement par estampilles
2.5 Les applications avancées
 D'après G. Gardarin
2.1 Objectifs




Permettre l'exécution simultanée d'un nombre important
de transactions.
Régler les conflits d'accès lecture (accès partagé)/ écriture
(accès exclusif).
Conserver de bonnes performances.
Eviter les inter-blocages.
‹#›
 D'après G. Gardarin
Les problèmes des accès concurrents

Perte d'une mise à jour effectuée par une autre transaction
 { T1 : Lire A->a;



 T1: a*2 ->a;
 T1: Écrire a -> A
 }

T2 : Lire A->b;
T2 : b+1 -> b;
T2 : Écrire b->A;
Introduction d'incohérences dans la base
 A = B // contrainte d'intégrité
 { T1 : A*2->A;

T2 : A+1->A;

T2 : B+1 -> B;

T1 : B*2 -> B
 }
‹#›
 D'après G. Gardarin
Les problèmes des accès concurrents

Non reproductibilité de certaines lectures
 { T1 : Lire A->a;



 T1: Lire A -> a
 }
‹#›
T2 : Lire A->b;
T2 : b+1 -> b;
T2 : Écrire b->A;
 D'après G. Gardarin
2.2 Les définitions de base

Granule de concurrence
 Unité de données dont les
individuellement par le SGBD.

accès
sont
contrôlés
Action
 Unité indivisible exécutée par le SGBD sur un granule pour
un utilisateur, constituée généralement par une opération de
lecture ou d'écriture.

Exécution de transaction
 Séquence d'actions obtenues en intercalant les diverses
actions des transactions T1,T2,…,Tn tout en respectant
l'ordre interne de chaque transaction.
‹#›
 D'après G. Gardarin
2.2 Les définitions de base (suite)


Chaque transaction Ti est composée d'une séquence
d'actions <a11, a12, ..., a1n>.
Une exécution simultanée (histoire) des transactions
{T1, T2, .... Tn} est une séquence d'actions
 H = < ai1j1, ai2j2 .... aikjk > telle que aij < aij+1 pour tout i et
tout j et quel que soit aij de T1,…, Tn, aij est dans H
 C'est une séquence d'actions complète respectant l'ordre des
actions des transactions.

Une exécution est sérielle si toutes les actions des
transactions ne sont pas entrelacées.
 Elle est de la forme
 <Tp(1), Tp(2), ...Tp(n)> ou p est une permutation de 1, 2, ... n.
‹#›
 D'après G. Gardarin
Sérialisabilité

Exécution sérialisable
 Une exécution est dite sérialisable si elle est équivalente à
une exécution sérielle.

Plusieurs critères d'équivalence possibles
 Équivalence de vue : tous les résultats visibles sont
identiques.
 Équivalence de conflit : toutes les actions conflictuelles sont
effectuées dans le même ordre sur les objets de la base.
‹#›
 D'après G. Gardarin
Graphe de précédence


Précédence : propriété stipulant qu'une transaction a accompli
une opération Oi sur une donnée avant qu'une autre transaction
Oj n'y accomplisse une opération, les transactions Oi et Oj étant
non commutatives.
La technique est basée sur la seule sémantique des opérations
de lecture / écriture
 "Ti lit l'objet O" avant "Tj écrit l'objet O" => Ti précède Tj
 "Ti écrit l'objet O" avant "Tj écrit l'objet O" => Ti précède Tj

Condition de sérialisabilité
 Le graphe de précédence doit rester sans cycle.


La sérialisabilité est une condition suffisante de correction.
Exercice
 Démontrer que les cas de perte d'opérations et d'incohérences sont non
sérialisables.
‹#›
 D'après G. Gardarin
2.3 Le Verrouillage à deux phases


Verrouillage à deux phases (Two Phases Locking)
 Technique de contrôle des accès concurrents consistant à verrouiller les
objets au fur et à mesure des accès par une transaction et à relâcher les
verrous seulement après obtention de tous les verrous demandés.
Principes
 Verrouillage des objets en lecture/écriture.
 Opérations de verrouillage Lock(g,M) et de déverrouillage Unlock(g)
 Compatibilité des opérations de lecture/écriture.
L
E
L : Lecture
L V
F
E : Ecriture
E
F
F
 Toute nouvelle transaction doit attendre la fin des transactions
incompatibles.
 La théorie garantit un graphe de précédence sans cycle.
 Rappelons que l'existence d'un cycle peut créer un verrou mortel.
‹#›
 D'après G. Gardarin
Condition de corrections


Transactions à deux phases (Two phases Commit)
Principe de base : une transaction ne peut relâcher un
verrou avant de les avoir tous acquis.
Nombre
de verrous
temps
j
‹#›
 D'après G. Gardarin
Algorithmes de l'opération Lock

Bool Function Lock(Transaction t, Objet O, Mode M)
 {Cverrou := 0 ;
Pour chaque transaction i  t ayant verrouillé l'objet O faire
{Verrou := Verrou  t.verrou(O) } ; // cumul des verrous sur l'objet
si Compatible (Mode, Verrou) alors
{t.verrou(O) = t.verrou(O)  M; // marquer l'objet verrouillé
Lock := true ;
}
sinon {insérer (t, Mode) dans la queue de O ;
// mise en attente de transaction
bloquer la transaction t ;
Lock := false ;
};
}
‹#›
 D'après G. Gardarin
Algorithme de l'opération Unlock

Procédure Unlock(Transaction t, Objet O)
{t.verrou(O) := 0 ;
Pour chaque transaction i dans la queue de O
{si Lock(i, O,M) alors
{enlever (i,M) de la queue de O ; débloquer i ;} ;
}
}
‹#›
 D'après G. Gardarin
Problèmes liés au verrouillage

Verrou mortel
 Risques de cycles d'attente entre transactions.
T2
T1

Granularité des verrous
T3
 au niveau page : de petits objets risquent d'être verrouillés
en trop grands nombres
 au niveau objet : nombre trop important de verrous, d'où une
gestion difficile
‹#›
 D'après G. Gardarin
Résolution du verrou mortel

Prévention
 Définition de critères de priorité pour éviter que le problème
ne se pose.
 Exemple : priorité aux transactions les plus anciennes.

Détection
 Gestion du graphe des attentes.
 Lancement d'un algorithme de détection de cycles dès
qu'une transaction attend trop longtemps.
 Choix d'une transaction victime pour briser le cycle.
‹#›
 D'après G. Gardarin
Améliorations du verrouillage

Relâchement des verrous en lecture après opération
- : non garantie de la reproductibilité des lectures.
+ : verrous conservés moins longtemps.

Accès à la version précédente lors d'une lecture
rendue bloquante
- : nécessité de conserver une version antérieure (journaux).
+ : une opération de lecture n'est pas bloquante en général.
‹#›
 D'après G. Gardarin
Granularité variable

Plusieurs granules de verrouillage
sont définis, imbriqués les uns
dans les autres.
base
classe

Le verrouillage s'effectue en mode
intention
sur
les
granules
supérieurs et en mode effectif sur
les granules choisis
cluster
page
objet
 Les modes intentions sont compatibles.
 Les modes effectifs et intentions obéissent
aux règles de compatibilité classiques.
‹#›
 D'après G. Gardarin
Algorithme du verrouillage altruiste

Restitution des verrous sur les données qui ne sont plus
utilisées
 L'abandon d'une transaction provoque des cascades
d'abandons.
 Nécessité d'introduire la portée d'une transaction (transaction
ouverte).
Objets
a
T2
T1
-
b
T3
-
c
d
,
,
e
‹#›
 D'après G. Gardarin
Temps
Degré d'isolation en SQL2

Définition de degrés d'isolation emboîtés
 Degré 0


Garantit les non pertes des mises à jour.
Pose de verrous exclusifs courts lors des écritures.
 Degré 1


Garantit la cohérence des mises à jour.
Pose de verrous exclusifs longs en écriture.
 Degré 2


Garantit la cohérence des lectures individuelles.
Pose de verrous partagés courts en lecture.
 Degré 3


‹#›
Garantit la reproductibilité des lectures.
Pose de verrous partagés longs en lecture.
 D'après G. Gardarin
Bilan sur le principe du verrouillage

C'est une approche pessimiste
 prévient les conflits,
 assez coûteuse,
 assez complexe.

Approche retenue
 Dans tous les SGBD industriels.

Difficile de faire mieux !
‹#›
 D'après G. Gardarin
2.4 Ordonnancement par estampillage

Estampille (TimeStamp) associée à chaque transaction
 Date de lancement,
 Garantie d'ordre total (unicité).

Conservation des estampilles
 Dernier écrivain Écrire r
 Plus jeune lecteur Lire er

Contrôle d'ordonnancement
 En écriture: estampille écrivain > Écrire r et > Lire er
 En lecture: estampille lecteur > Écrire r

Problèmes
 Reprise de transaction en cas d'accès non sérialisé
 Risque d'effet domino en cas de reprise de transaction
‹#›
 D'après G. Gardarin
Algorithme d'ordonnancement

Fonction Lire (Transaction t, Objet O) {
si O.Écrire r  t alors {
Lire := Get(O) ; // effectuer la lecture
O.Lire er := MAX (O.Lire er,t) ; // mettre à jour dernier
lecteur }
sinon Abort(t); } .

Fonction Écrire (Transaction t, Objet O, Contenu C){
si O.Écrire r  t et O. Lire er  t alors{
Set(O,C) ; // effectuer l'écriture
O.Écrire r := t ; // mettre à jour dernier écrivain }
sinon Abort(t); } .
‹#›
 D'après G. Gardarin
La certification optimiste

Les contrôles sont effectués seulement en fin de
transaction
 Phase d'accès: les OIDs des objets lus/écrits sont conservés.
 Phase de certification : vérification de l'absence de conflits
(L/E ou E/E sur un même objet) avec les transactions certifiée
pendant la phase d'accès.
 Phase d'écriture (commit) pour les transactions certifiées.

Avantages et inconvénients:
+ : test simple d'intersection d'ensembles d'OIDs en fin de
transaction.
- : tendance à trop de reprises en cas de conflits fréquents
(effondrement).
‹#›
 D'après G. Gardarin
Bilan Estampillage

Approche optimiste
 coût assez faible,
 détection et guérison des problèmes.

Guérison difficile
 Catastrophique en cas de nombreux conflits.
 Absorbe mal les pointes de charge.

Sophistication
 Ordonnancement multi-versions
‹#›
 D'après G. Gardarin
2.5 Techniques avancées et modèles étendus

Transactions longues
 Mise à jour d'objets complexes.
 Sessions de conception.

Prise en compte de la sémantique des applications
 Opérations commutatives (e.g., ajouts d'informations).
 Essais concurrents.

Travail coopératif
 Modèles concurrents plutôt que séquentiels.
‹#›
 D'après G. Gardarin
Commutativité d'Opérations

Possibilité de distinguer d'autres opérations que celles
de Lecture/Ecriture
 Chaque objet est doté de sa liste d'opérations (méthodes).
 Les opérations commutatives n'entraînent pas de conflits.
 La commutativité peut dépendre du résultat.

Cas des ensembles
[Ins,ok]
insertion avec succès
[Del,ok]
suppression avec succès
[In, true]
appartenance avec succès
[In, False] appartenance avec échec
‹#›
 D'après G. Gardarin
Commutativité d'Opérations
[Ins,ok]
[Del,ok]
[In, true]
[In, False]
[Ins,ok]
1
0
0
0
[Del,ok]
0
1
0
1
[In, true]
0
0
1
1
[In, False]
0
1
1
1
Matrice de commutativité
‹#›
 D'après G. Gardarin
Contrôleur de Commutativité

Un contrôle de concurrence défini au niveau de la classe
opère sur chaque objet.
 Il autorise les opérations commutatives.
 Il bloque les opérations non commutatives (ordonnancement).

Le modèle est ouvert et nécessite
 soit des transactions de compensations,
 soit la gestion de listes de transactions dépendantes.

Un potentiel pour les SGBDO non encore implémenté
(complexe)
‹#›
 D'après G. Gardarin
Transactions Imbriquées

 Obtenir un mécanisme de reprise
multi-niveaux
 Permettre de reprendre des parties
logiques de transactions
 Faciliter l'exécution parallèle de
sous-transactions

Begin(T)
Objectifs
Schéma
Begin(t'1)
Begin(t1)
Commit(t1)
Commit(t'1)
Commet t1
Begin(t2)
 Reprises et abandons partiels
 Possibilité d'ordonner ou non les
sous-transactions
Begin(t21)
Commit(t21)
Abort(t2)
Commit(T)
‹#›
Annule t2 et t21
 D'après G. Gardarin
Verrouillage et Transactions Imbriquées




Chaque transaction peut acquérir ou relâcher des
verrous.
Un verrou est accepté si l'objet est libre ou verrouillé par
un ancêtre.
Les verrous non relâchés sont restitués à la transaction
mère.
Problèmes de conflits entre sous-transactions parallèles
 Risque de verrous mortels,
 L'ancêtre commun peut trancher.

Gestion de journaux multi-niveaux
 Organisation sous forme de piles,
 Nécessité de journaux multiples en cas de parallélisme.
‹#›
 D'après G. Gardarin
Sagas


Groupe de transactions ordonnées avec transactions
compensatrices.
En cas de panne du groupe, les transactions de
compensation sont exécutées.
T1
T1
‹#›
T2
T2
T3
CT2
Tn
...
CT1
 D'après G. Gardarin
Activités : propriétés souhaitées



Contexte persistant.
rollforward, rollback avec compensations.
Flot de contrôle dépendant des succès et échecs.
 différencier les échecs systèmes des échecs de programmes.

Monitoring d'activités:
 état d'une activité, arrêt, ...
‹#›
 D'après G. Gardarin
Langage de Contrôle d'Activités

Exemple: réservation pour départ en vacances
 T1 : réservation avion alternative : location voiture
 T2 : réservation hôtel
 T3 : location voiture

Activité
 Ensemble d'exécution de transactions avec alternative ou
compensation.

Langage de contrôle d'activités
 Possibilité de définir un transaction vitale (ex: réservation
hôtel).
 Langage du type :

‹#›
If abort, If commit, Run alternative, Run compensation, …
 D'après G. Gardarin
Transaction multi-niveaux
BD PARTAGEE
Objet
Versionnable
V2
V1
BD PERSONNELLE
CheckOut
Version
Personnelle
CheckIn
V3
CheckOut
Version
Personnelle
V4
‹#›
CheckIn
 D'après G. Gardarin
CheckOut/CheckIn

ChechOut
 Opération d'extraction d'un objet de la BD pour en dériver une
nouvelle version.

CheckIn
 Opération de réinstallation d'une nouvelle version de l'objet
dans la BD.
Lecture
Lecture
1
Ecriture
0
COut P
1
COut E
0
Ecriture
0
0
0
0
COut Partagée
1
0
1
0
COut Exclusif
0
0
0
0
‹#›
 D'après G. Gardarin
Fusion des Versions

Maintient différentiel
 Seuls les objets/pages modifiés sont maintenus.

Aucun objets communs n'est modifié
 La fusion est une union des "deltas".

Des objets communs sont modifiés
 Nécessité d'intervention manuelle (choix).
‹#›
 D'après G. Gardarin
2.6 Conclusions

Technique d'amélioration du verrouillage






Transactions ouvertes.
Granularité variable.
Commutativité des opérations.
Transactions imbriquées.
Versions.
Amélioration des modèles transactionnels
 Gestion des transactions imbriquées.
 Sagas, Activités, Versions.

Beaucoup d'idées, peu d' implémentations originales
 La plupart des systèmes utilise le verrouillage type SQL
‹#›
 D'après G. Gardarin
3.Gestion de transactions




3.1. Journaux et reprise
3.2. Scénarios de reprise
3.3. Modèles étendus
3.4. Cas des systèmes répartis
‹#›
 D'après G. Gardarin
3.1 Journaux des mises à jour

Journal des images avant
 Journal contenant les débuts de transactions, les valeurs
d'enregistrement avant mises à jour, les fins de transactions
(commit ou abort)
 Il permet de défaire les mises à jour effectuées par une
transaction

Journal des images après
 Journal contenant les débuts de transactions, les valeurs
d'enregistrement après mises à jour, les fins de transactions
(commit ou abort)
 Il permet de refaire les mises à jour effectuées par une
transaction
‹#›
 D'après G. Gardarin
Journal des images avant

Utilisé pour défaire les mises à jour : Undo
2.Log
Page lue
Page modifiée
3.Update
1.Read
4.Write
Base de données
‹#›
 D'après G. Gardarin
Journal des images après

Utilisé pour refaire les mises à jour : Redo
3.Log
Page lue
Page modifiée
2.Update
1.Read
4.Write
Base de données
‹#›
 D'après G. Gardarin
Gestion des journaux



Journaux avant et après sont unifiés.
Écrits dans un tampon en mémoire et vidés sur disque
en début de l'opération commit
Structure d'un enregistrement :





N° transaction (Trid)
Type enregistrement {début, update, insert, commit, abort}
TupleId
[Attribut modifié, Ancienne valeur, Nouvelle valeur] ...
Problème de taille
 On travaille avec N fichiers de taille fixe.
 Possibilité d'utiliser un fichier haché sur Trid/Tid.
‹#›
 D'après G. Gardarin
Sauvegarde

Sauvegarde périodique de la base
 toutes les heures, jours, ...
 Doit être effectuée en parallèle aux mises à jour.

Point de Reprise (Checkpoint)
 Un Point de Reprise est écrit dans le journal pour le
synchroniser par rapport à la sauvegarde. Il permet de situer
les transactions effectuées après la sauvegarde.

Pose d'un point de reprise
 écrire les tampons de journalisation (Log).
 écrire les tampons de pages (DB).
 écrire un enregistrement spécial "checkpoint" dans le
journal.
‹#›
 D'après G. Gardarin
3.2 Scénarios de Reprise

Les mises à jour peuvent être effectuées directement
dans la base (en place)
 la base est mise à jour immédiatement, ou "dès que
possible" pendant que la transaction est active.

Les mises à jour peuvent être effectuées en mémoire
et installées dans la base à la validation (commit)
 le journal est écrit avant l'écriture des mises à jour.
‹#›
 D'après G. Gardarin
Stratégie do-undo (faire/défaire)

Mises à jour en place
 l'objet est modifié dans la base.

Utilisation des images avant
 copie de l'objet avant mise à jour.
 utilisée pour défaire en cas de panne.
Update
2. LogPage
Mémoire
cache
Journal avant
3. WritePage
Undo
1. LirePage
Base
‹#›
 D'après G. Gardarin
Stratégie do-redo (faire/refaire)

Mises à jour en mode différentiel
 L'objet est modifié en page différentielle (non en
place/journal).

Utilisation des images après
 copie de l'objet en journal après mise à jour (do),
 utilisée pour refaire en cas de panne (redo).
Update
3. LogPage
Mémoire
cache
2. WritePage
Redo
1. LirePage
Base
‹#›
Journal après
Ombre
Commit
 D'après G. Gardarin
Pages ombres
Table des Pages Ombres
Nom
Fichier
Adresse
COMMIT
Table des
Pages
Page Ombre
Page Ombre
Nouvelle Table des Pages
Nouvelles Pages
‹#›
 D'après G. Gardarin
La gestion des tampons (buffers)

Gestion des caches et des des journaux
 Écriture du journal lorsqu'un tampon est plein,
 ou lorsqu'une transaction commet.

Gestion des caches et des bases
 Modification de la la page en mémoire.
 Vidage du cache sur disque effectué en différé (processus
E/S).

Synchronisation journaux / base
 Le journal doit toujours être écrit avant la modification de la
base !
‹#›
 D'après G. Gardarin
Commits bloqués

Afin d'éviter 3 e/s pour 1:
 Le système reporte l'enregistrement des journaux à la phase
commit.
 Plusieurs transactions sont commises simultanément.
 Les transactions à commettre sont mises en attente pour
bloquer un unique tampon d'écriture dans le journal.

Résultat
 La technique des "commits" bloqués permet d'améliorer les
performances lors des pointes sans excès d'attente trop
sensible pour les transactions.
‹#›
 D'après G. Gardarin
Reprise à froid



En cas de perte d'une partie de la base, on repart de la
dernière sauvegarde.
Le système retrouve le checkpoint associé.
Il ré-applique toutes les transactions commises depuis
ce point .
 (for each committed Ti : redo (Ti))
‹#›
 D'après G. Gardarin
3.3 Journalisation et modèles étendus



Rappelons qu'ils s'agit d'applications longues
composées de plusieurs transactions coopérantes.
Seules les mises-à-jour sont journalisées.
Si nécessité de défaire une suite de transactions :
 contexte ad-hoc stocké dans une table temporaire,
 nécessité d'exécuter des compensations.
‹#›
 D'après G. Gardarin
Points de Sauvegardes

Introduction de points de sauvegarde intermédiaires
 (savepoint, commitpoint)

Begin_Trans






‹#›
update
update
savepoint
update
update
unité d'oeuvre
Non perte du contexte
unité d'oeuvre
Commit
 D'après G. Gardarin
3.4 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
// Une panne provoque une incohérence des données
 FIN

Problème
 Le contrôle étant réparti, chaque site peut librement décider
de valider ou d'annuler ...
‹#›
 D'après G. Gardarin
Commit à 2 Phases : principes et définitions

Principe
 Division de l'opération COMMIT en deux phases :
 Phase 1


Préparation de l'écriture des résultats des mises à jour dans la BD.
Centralisation du contrôle.
 Phase 2


Écriture des résultats dans la BD.
Coordinateur de l'opération
 Le composant système d'un site qui applique le protocole.

Participant
 Le composant système d'un autre site participant à
l'exécution de la transaction.
‹#›
 D'après G. Gardarin
Commit en 2 Phases : protocole C/S

1. Préparer
 Le coordinateur demande aux autres sites s'ils sont prêts à
commettre leur mise à jour.

2a. Succès : 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
à chacun des sites participants.
‹#›
 D'après G. Gardarin
Cas favorable
SITE COORDINATEUR
SITE PARTICIPANT 2
SITE PARTICIPANT 1
PREPARE
OK
COMMIT
ACK
‹#›
PREPARE
OK
COMMIT
ACK
 D'après G. Gardarin
Cas défavorable (1)
SITE COORDINATEUR
SITE PARTICIPANT 2
SITE PARTICIPANT 1
PREPARE
PREPARE
OK
KO
ABORT
ABORT
ACK
ACK
‹#›
 D'après G. Gardarin
Cas défavorable (2)
SITE COORDINATEUR
SITE PARTICIPANT 2
SITE PARTICIPANT 1
PREPARE
OK
COMMIT
PREPARE
OK
COMMIT
ACK
STATUS
COMMIT
ACK
‹#›
 D'après G. Gardarin
Commit distribué ou centralisé

Validation à deux phases centralisée
Prepare

OK
Commit
OK
Possibilité de diffuser la réponse au PREPARE
 chaque site peut décider localement dans un réseau sans perte
OK
Prepare
‹#›
 D'après G. Gardarin
Transitions d'états
Initia
l
CCommit/Prepare
Wait
VoteKO/GAbort
Abort
VoteOK/GCommit
Initial
Commit
Prepare/VoteOK
COORDINATEUR
Ready
GAbort/Ack
Abort
GCommit/Ack
Commit
PARTICIPANT
‹#›
 D'après G. Gardarin
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.
 D'après G. Gardarin
Commit en 3 Phases

 en cas de time-out en état “Prêt”,
le participant est bloqué
 le commit à 3 phases permet
d'éviter les blocages

Initial
Inconvénient du commit à 2
phases
CCommit/Prepare
VoteKO/GAbort
Prepare,
Prepare to Commit,
Global-Commit,
Global-Abort.
VoteOK/PréCommit
Abort
PréCommit
PréOK/GCommit
Commit
Messages du commit à 3
phases




Wait
Initial
Prepare/VoteOK
GAbort/Ack
Abort
Ready
PréCommit/PréOK
PréCommit
GCommit/Ack
Commit
‹#›
 D'après G. Gardarin
Protocole arborescent TP


TP est le standard proposé par
l'ISO dans le cadre OSI
Protocole arborescent
 Tout participant peut déclencher une
sous-transaction.
 Un responsable de la validation est
choisi.
 Un coordinateur est responsable de ses
participants pour la phase 1.


Coordinateur global
Coordinateur local
Coordinateur localPoint de validation
(Noeud critique)
collecte les PREPARE
demande la validation
 Le point de validation est responsable de
la phase 2

‹#›
envoie les COMMIT.
 D'après G. Gardarin
4. Moniteurs transactionnels





Support de transactions ACID
Accès continu aux données
Reprise rapide du système en cas de panne
Sécurité d'accès
Performances optimisées
 Partage de connexions.
 Réutilisation de transactions.

Partage de charge
 Distribution de transactions.


‹#›
Support de bases hétérogènes
Respect des normes et standards
 D'après G. Gardarin
Moniteur transactionnel : modèle

Modèle DTP de l'X/OPEN
 Programme d'application AP
 Gestionnaire de transactions TM
 Gestionnaire de communication
CRM
 Gestionnaire de ressources RM

TX
TM
Interfaces standards
 TX = interface du TM
 XA = interface du RM
 intégration de TP

AP
CRM
TM
XA
Types de RM
 gestionnaire de fichiers
 SGBD
 périphérique
‹#›
RM
 D'après G. Gardarin
Interface applicative TX

tx_open
 ordonne au TM d'initialiser la communication avec tous les
RM dont les librairies d'accès ont été liées à l'application.

tx_begin
 ordonne au TM de demander aux RM de débuter une
transaction.

tx_commit ou tx_rollback
 ordonne au TM de coordonner soit la validation soit
l'abandon de la transaction sur tous les RM impliqués.

tx_set_transaction_timeout
 positionne un “ timeout ” sur les transactions

tx_info
 permet d'obtenir des informations sur le statut de la
transaction.
‹#›
 D'après G. Gardarin
Interface ressource XA

xa_open
 ouvre un contexte pour l'application.

xa_start
 débute une transaction.

xa_end
 indique au RM qu'il n'y aura plus de requêtes pour le compte
de la transaction courante.

xa_prepare
 lance l'étape de préparation du commit à deux phases.

xa_commit
 valide la transaction.

xa_rollback
 abandonne la transaction.
‹#›
 D'après G. Gardarin
Principaux moniteurs (1)

Encina de Transarc





Issu de CMU (1992), racheté par IBM
Construit sur DCE (OSF) pour la portabilité et la sécurité
Transactions imbriquées
Conformité DTP : Xa, CPI-C, TxRPC
Open CICS de IBM
 Construit sur Encina (et DCE)
 Reprise de l'existant CICS (API et outils)
 Conformité DTP : Xa, CPI-C
‹#›
 D'après G. Gardarin
Principaux moniteurs (2)

Tuxedo de USL
 Éprouvé (depuis 1984), à la base de DTP
 Supporte l'asynchronisme, les priorités et le routage
dépendant des données
 Conformité DTP: Xa, Tx, XaTMI, CPI-C, TxRPC

Top End de NCR
 Produit stratégique d'AT&T
 Respecte le modèle des composants DTP (AP, RM, TM,
CRM)
 Haute disponibilité
 Conformité DTP: Xa, Xa+, Xap-Tp, Tx

‹#›
Autres : UTM de Siemens, Unikix
 D'après G. Gardarin
Le marché
900
800
700
Tuxedo
600
millions $
Encina
500
CICS
400
UTM
300
TOP END
200
Autres
100
0
1994
1995
1996
1997
Gartner Group
‹#›
 D'après G. Gardarin
MTS de Microsoft





Microsoft Transaction Server
Intégré à DCOM
Partage de grappes de NT (cluster)
Les disques sont supposés partagés.
Allocation des ressources en pool aux requêtes :
 pool de connexion aux ressources (SQL Server),
 pool de transactions (support),
 pool de machines.

Ne respecte pas les standards !
‹#›
 D'après G. Gardarin
Conclusion sur les moniteurs transactionnels





Des techniques complexes.
Un problème bien maîtrisé dans les SGBDR.
La concurrence complique la gestion de transactions.
Les transactions longues restent problématiques.
Enjeu essentiel pour le commerce électronique.




‹#›
validation fiable
reprise et copies
partage de connections
partage de charge
 D'après G. Gardarin