Gestion des Accès Concurrents

TRANSACTIONS

Gestion des Accès Concurrents

MODELE de traitementSQLSQL

/* Transaction 1 */SELECT * FROM …UPDATE …SAVEPOINT …DELETE FROM …UPDATE …ROLLBACK TO …INSERT INTO …COMMIT;

/* Transaction 2 */SELECT * FROM …UPDATE ……

SessionApplication Serveur

NOTION de Transaction

Besoin des applications multi-utilisateurs : Garantir la durabilité des donnéesGarantir leur cohérence

Notion de transaction :

une transaction est une unité logique d’instructions SQL qui vérifie des propriétés ACID

PROPRIETES ACID

atomicité:Soit toutes les instructions de la transaction sont validées, soit toute la transaction est annulée

Durabilité : Une transaction validée doit garantir la durabilité des données dans le temps (problème de panne)

Cohérence: Une transaction doit assurer la cohérence des données qu ’elle manipule dans un contexte multi-utilisateur

Isolation : Une transaction s ’exécute en respectant des niveaux d ’isolation des données

ATOMICITE et Durabilité d ’une transaction

Valider une transaction signifie rendre ses mises à jour de la base permanentes (Durables)

Syntaxe SQL : COMMITInvalider une transaction signifie annuler toutes ses mises à jour dans la base

Syntaxe SQL : ROLLBACK

Début d'une transaction sous ORACLELa première instruction SQL exécutable (LMD, LDD)

Suite à une connexionSuite à la fin de la transaction précédente

La fin d'une transaction peut être implicite ou explicite (COMMIT, ROLLBACK)

VALIDATION et invalidation d'instructions

Les effets d'une instruction SQL peuvent être défaits ou invalidés

A cause d'une erreur d'exécution

A cause d'une détection d'interblocage

L'invalidation d'une instruction n'entraîne pas automatiquement l'invalidation de sa transaction

En PL/SQL, si un sous-programme stocké échoue avec une exception non traitée, ORACLE déroule en arrière (rollback) tout le travail effectué par ce sous-programme

VALIDATION /Invalidation implicite de transactions

Avant l'exécution d'une instruction LDD, une validation implicite de la transaction en cours a lieu

Cette validation est maintenue quelle que soit l'issue de l'instructionSi l'instruction LDD réussit, une validation implicite à sa fin est également exécutée

Quel que soit l'environnement d'exécutionUne déconnexion normale provoque une validation implicite de la transaction en coursUne déconnexion anormale implique une invalidation de la transaction en cours

VALIDATION / Invalidation explicite

La commande COMMIT

COMMIT [ WORK ]

La commande ROLLBACK

ROLLBACK [ WORK ] [ TO [ SAVEPOINT ] savepoint ]

Le point de reprise est créé par la commande SAVEPOINT

SAVEPOINT savepoint

EXEMPLE de Transactions

Scénario a dérouler :

1°) Vérifier le contenu de la table pilote2°) Insérer un tuple dans la table3°) Insérer un point de reprise à ce stade4°) Mettre à jour un ou plusieurs tuples5°) Insérer un deuxième point de reprise6°) Dérouler en arrière votre transaction jusqu'au premier point de reprise7°) Vérifier l'impact sur la table8°) Essayer de dérouler votre transaction jusqu'au deuxième point de reprise9°) Valider votre transaction10°)Vérifier l'impact sur la table11°) Invalider en utilisant ROLLBACK et vérifier l'impact sur la table

Conclusions?

ISOLATION des Transactions

Anomalies potentielles rencontrées lors de l ’exécution simultanée de transactions :

Lecture impropreLecture non reproductibleRéférence fantôme

La Norme SQL2 Prévoit 4 niveaux d ’Isolation des transactions sur un SGBD

NIVEAUX d'isolation des transactions dans SQL

LectureImpropre

Lecture nonreproductible

Lecture defantômes

Readuncommited

Oui Oui Oui

Readcommited

Non Oui Oui

Repeatableread

Non Non Oui

serializable Non Non Non

Gestion des transactionsdans Oracle

La gestion standard

PROBLEMES liés à la concurrence

Deux problèmes majeurs se posentAccès simultané aux mêmes données par des transactions concurrentesL'exécution concurrente de deux transactions, est-elle équivalente à une exécution séquentielle quelconque des mêmes transactions?

Problème de sérialisabilité des exécutions concurrentes des transactions

SolutionsUtilisation des verrous (1er et 2ème problème)Détection des interblocages (1er et 2ème problème)Transactions à 2 phases (2ème problème)

EXEMPLE d ’accès concurrent sur ORACLE (1/3)

Transaction 1

1°) ...

2°) UPDATE Pilote SET Salaire = ...WHERE Matricule = 10;

3°) SELECT Salaire FROM PiloteWHERE Matricule = 10;

4°) COMMIT;5°) ...

Transaction 2


2°) ...


4°) ...5°) SELECT Salaire FROM Pilote

WHERE Matricule = 10;

Conclusion ?


Transaction 1

1°) COMMIT; (ou ROLLBACK;)2°) ...

3°) SELECT Salaire FROM Pilote;4°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = 2;5°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = 1;6°) ...

Transaction 2

1°) COMMIT; (ou ROLLBACK;)2°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = 1;3°) SELECT Salaire FROM Pilote;4°) ...

5°) ...

6°) COMMIT;

Conclusion ?


Transaction 1


WHERE Matricule = 20;3°) SELECT Salaire FROM Pilote;4°) UPDATE Pilote SET Salaire = ...


Transaction 2


WHERE Matricule = 10;3°) SELECT Salaire FROM Pilote;4°) UPDATE Pilote SET Salaire = ...


Conclusion ?

GESTION standard des Verrous ORACLE

L'acquisition de verrous est graduelle au niveau des instructions de la transaction

Un verrou, une fois acquis, n'est libéré qu'à la fin de la transaction (transactions à deux phases)

Une lecture n'est bloquée par aucune autre opération et vice versaDétection automatique d'interblocagesVerrouillage au niveau de tuplesProblème de sérialisabilité

Blocage minimal des transactions concurrentesBlocage minimal des transactions concurrentes

VERROUILLAGE standard dans Oracle

SELECT

VerrouillageInstruction SQL TableTuple

INSERT

UPDATE

DELETE

Instruction LDD

- -

X

X

X

RX

RX

RX

X-

ALTERNATIVES au verrouillage standard

La stratégie de verrouillage par défaut n'est pas valable pour toutes les applications

Oracle offre plusieurs solutions

Transactions en lecture seule

Utilisation du verrouillage

explicite

Verrouillage de tables Verrouillage de tuples

Transactions sérialisables


Utilisation de SET TRANSACTION

CONFIGURATION du niveau d'isolation

Pour toutes les transactions d'une session

ALTER SESSION SET ISOLATION LEVEL SERIALIZABLE

ALTER SESSION SET ISOLATION LEVEL READ COMMITED

Pour une seule transaction

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

SET TRANSACTION ISOLATION LEVEL READ COMMITED

EXEMPLE d ’accès concurrent sur ORACLE

Transaction 11°) COMMIT; (ou ROLLBACK;)2°) …

3°) ...4°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = 10;5°) COMMIT;6°) …7°) …

8°) …

Transaction 21°) COMMIT; (ou ROLLBACK;)2°) SET TRANSACTION ISOLATION

LEVEL SERIALIZABLE;3°) SELECT Salaire FROM Pilote;4°) ...

5°) ...6°) SELECT Salaire FROM Pilote;7°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = 20;8°) UPDATE Pilote SET Salaire = ...


Conclusion ?

CONSISTANCE des lectures

Deux niveaux de consistanceNiveau instruction SQL

Toujours assuré par OracleNiveau transaction

Forcer la consistance des lectures au niveau de la transaction par l’instruction

SET TRANSACTION READ ONLYDoit être la première instruction dans une transactionInstructions permises

SELECT sauf avec la clause FOR UPDATELOCK TABLE, SET ROLEALTER SESSION, ALTER SYSTEM


Transaction 1

1°) COMMIT; (ou ROLLBACK;)2°) ...3°) ...4°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = 1;5°) COMMIT;6°) ...

Transaction 2

1°) COMMIT; (ou ROLLBACK;)2°) SET TRANSACTION READ ONLY;3°) SELECT Salaire FROM Pilote;4°) ...

5°) ...6°) SELECT Salaire FROM Pilote;

Conclusion ?


Verrouillage explicite

VERROUILLAGE explicite dans Oracle

Deux instructions sont disponiblesSELECT ... FOR UPDATE;

Verrouillage explicite de tuplesLOCK TABLE ... IN ... MODE;

Verrouillage explicite de tablesL'utilisation de LOCK TABLE donne au développeur plus de contrôle sur le degré de concurrence souhaité pour l'accès aux données

Il faut néanmoins bien connaître les besoins de l'application afin de choisir les verrous appropriés

Dans tous les cas, les verrous acquis ne sont libérés qu'à la fin de la transaction

INSTRUCTION « SELECT ... FOR UPDATE »

Cette instruction indique à Oracle d'anticiper une mise à jour éventuelle des tuples sélectionnés

Un verrou est posé alors sur chaque tuple sélectionnéUn verrou de type RS est aussi posé sur la table

Il est possible d'utiliser l'option NOWAIT afin d'éviter l'attente de disponibilité des tuples concernés

Une erreur d'exécution de l'instruction se produit alors et aucun tuplen'est sélectionné

Si l'instruction est associée à un curseur alors le verrouillage des tuples se fait à l'ouverture du curseur et pas au fur et à mesure en utilisant FETCHDéconseillée si la sélectivité est faible


Transaction 1

1°) UPDATE Pilote SET Salaire = ...WHERE Matricule = mat1;

2°) ...

3°) …

4°) …

5°) COMMIT;6°) SELECT Salaire FROM Pilote;7°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = mat3;8°) UPDATE Pilote SET Salaire = ...

WHERE Matricule = mat1;9°) ...

Transaction 2

1°) ...

2°) SELECT Salaire FROM PiloteWHERE Matricule = mat2FOR UPDATE;

3°) SELECT Salaire FROM PiloteWHERE Matricule = mat1FOR UPDATE NOWAIT;

4°) SELECT Salaire FROM PiloteWHERE Matricule = mat1FOR UPDATE;

5°) ...6°) ...7°) …

8°) …

9°) COMMIT;

INSTRUCTION SQL « LOCK TABLE »

SyntaxeLOCK TABLE { table | vue } [ , { table | vue } ] ...

IN mode_de_verrouillage MODE [ NOWAIT ]

Modes disponiblesROW SHARE (RS)

ROW EXCLUSIVE (RX)

SHARE (S)

SHARE ROW EXCLUSIVE (SRX)

EXCLUSIVE (X)

BLOCAGE d’instructions dû aux verrous de tables

RS S XRX SRX

RS Non Non Non OuiNon

RX Non Oui

S Oui Oui

SRX Oui Oui

X Oui Oui

Non Oui Oui

Non Non Oui

Non Oui Oui

Oui Oui Oui

Acquis

Demandé

SELECT …FOR UPDATE

LOCK TABLE

INSERTUPDATEDELETELOCK TABLE

LOCK TABLE LOCK TABLE Instructions LDDLOCK TABLE


Session 1

1°) LOCK TABLE PiloteIN xxx MODE;

2°) SELECT * FROM Pilote;3°) …

4°) ...5°) SELECT * FROM Pilote;

6°) UPDATE PiloteSET Salaire = ...WHERE Matricule = 2;

Session 2

1°) …

2°) ...3°) UPDATE Pilote

SET Salaire = ...WHERE Matricule = 1;

4°) Commit;5°) ...

6°) ...

Session 3

1°) …

2°) ...3°) …

4°) ...5°) LOCK TABLE Pilote

IN SHARE MODE;6°) ...

1°) Le Verrou xxx de la transaction 1 doit être de type S pour que les 2 lecturesrendent le même résultat malgré la présence de la transaction 2?

2°) Le Verrou xxx de la transaction 1 doit être de type SRX pour assurer que l'étape 6 de la transaction 1 ne soit pas bloquée par l'étape 5 de la transaction 3?

CONCLUSIONS

☺ La libération des verrous est automatique et se fait à la fin de la transaction (transactions à deux phases)

☺ Oracle détecte toujours l'interblocage quel que soit la configuration utilisée

☺ Une interrogation sans pose de verrous n'est jamais bloquée dans Oracle

☺ Pour une concurrence maximale, utiliserla configuration par défaut de Oracle,sans verrouillage explicite,avec le niveau d'isolation par défaut

☺ Les alternatives ne manquent pas pour les applications ayant des besoins plus spécifiques

Gestion des Accès Concurrents

Documents

Transcript of Gestion des Accès Concurrents