Précédent Suivant Index

4   Concurrence d'accès

On va maintenant étudier le comportement concret d'un SGBD en cas d'accès concurrents à la même ressource. Pour celà on va simuler l'exécution concurrente de programmes à l'aide du petit ensemble de lectures/écritures sur la base ``Agence de voyage'' créé dans le premier exercice : modification du solde de certains clients et sélection des clients. Créez 4 fichiers, nommés SEL.sql, MAJpas.sql, MAJfog.sql et MAJker.sql et entrez-y les commandes suivantes :
  1. SEL.sql
           PROMPT 'Affichage des clients =>';
           SELECT * FROM client;
        
  2. MAJpas.sql
           PROMPT 'Augmentation du client Pascal =>';
           UPDATE client  SET solde = solde + 1000
           WHERE  client = 'Pascal';    
        
  3. MAJfog.sql
           PROMPT 'Augmentation du client Fogg =>';
           UPDATE client SET solde = solde + 1000
           WHERE  client = 'Fogg';   
        
  4. MAJker.sql
           PROMPT 'Augmentation du client Kerouac =>';
           UPDATE client SET solde = solde + 1000
           WHERE  client = 'Kerouac'; 
        
Ensuite, ouvrez deux fenêtres et lancez SQLPLUS dans chacune : chaque session est considérée par ORACLE comme un utilisateur, et on a donc 2 utilisateurs, nommés 1 et 2, en situation de concurrence. Dans tout ce qui suit, on note INSTRi l'exécution de l'instruction INSTR par l'utilisateur i. Par exemple MAJker1 corespond à l'exécution du fichier MAJker dans la première fenêtre par la commande @MAJker. On note de même ROLi et COMi l'exécution des commandes rollback; et commit; dans la fenêtre i.

Questions Executez les séquences d'instruction décrites ci-dessous. Dans chacun des cas, expliquez ce qui se passe.
  1. Première expérience : l'utilisateur 1 effectue des mises-à-jour, tandis que l'utilisateur 2 ne fait que des sélections. Que constate-t-on ?
    SEL1, SEL2, MAJker1, SEL2, MAJpas, SEL2, ROL1, SEL2.
  2. idem, mais avec des commit.
    SEL1, SEL2, MAJker1, SEL2, COM1, SEL2, MAJker1, SEl2, COM1, SEL2.
  3. Maintenant les deux utilisateurs effectuent des MAJ simultanées.
    SEL1, SEL2, MAJker1, MAJpas2, SEl1, SEL2, MAJfog1, MAJfog2, SEL1, COM1, COM2.
    Un bloquage est apparu. Pourquoi ?
  4. Idem, avec un ordre des opérations qui diffère d'un utilisateur à l'autre.
    SEL1, SEL2, MAJker1, MAJpas2, SEl1, SEL2, MAJpas1, MAJker2 ROL1 ROL2.
    Que constate-t-on ?
  5. (trèfle)En fait, ORACLE pratique une verrouilage à deux phases assez libéral, qui ne garantit pas la sérialisabilité : aucun verrrou n'est placé sur une ligne lors d'une lecture. L'utilisateur peut verrouiller explicitement en ajoutant la clause FOR UPDATE. Exemple :
    SELECT * FROM client FOR UPDATE;
    Chaque ligne sélectionnée est alors verrouillée. Refaites les expériences précédentes avec un verrouillage explicite des lignes que vous voulez modifier.
  6. (trèfle)Expérimentez les exécutions écédentes en spécifiant le mode suivant :
         SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
         

Précédent Suivant Index