## Scénario 1 ### Quelles seront les transactions validées, bloquées ou abandonnées ? #### TMPP - Transaction T1 annulée (ft1 == 0), car il essaie de read y à la date 5 alors que celui-ci est lock par T2 à la date 4. - Transaction T2 annulée (ft2 == 0), car il essaie de write z à la date 7 alors que celui-ci est lock par T3 à la date 6. - Transaction T3 validée (ft3 == 1), T1 et T2 ayant été annulés, T3 n'a pas de problème pour terminer sa transaction. #### TMPC - Transaction T1 validée (ft1 == 1) - Transaction T2 validée (ft2 == 1) - Transaction T3 annulée (ft3 == 0), car T3 la valeur de z est modifié entre son read par T3 à la date 6 et son commit date 16, par T2 à la date 7. ### TM2PL - Transaction T1 validée (ft2 == 1) - Transaction T2 validée (ft2 == 1) - Transaction T3 validée (ft3 == 1) Il n'y a pas d'interblocages, donc la politique de verouillage à deux phases fait se terminer toutes les transactions de l'exemple. ### Quelles seront les valeurs de variables affichées par la commande list ? #### TMPP ``` T_objets : ft1 0 ft3 1 ft2 0 x 3 y 0 z 0 ``` #### TMPC ``` T_objets : ft1 1 ft3 0 ft2 1 x 0 y 1 z 2 ``` #### TM2PL ``` T_objets : ft1 1 ft3 0 ft2 1 x 0 y 1 z 2 ``` ## Scénario 2 ### Quelles seront les transactions validées, bloquées ou abandonnées ? #### TMPP Transaction T1 validée (ft1 == 1), T2 et T3 ayant été annulés, T3 n'a pas de problème pour terminer sa transaction. Transaction T2 annulée (ft2 == 0), car il essaie de write z à la date 7 alors que celui-ci est lock par T3 à la date 6. Transaction T3 annulée (ft3 == 0), car il essaie de write x à la date 10 alors que celui-ci est lock par T1 à la date 5. #### TMPC - Transaction T1 validée (ft1 == 1). - Transaction T2 validée (ft2 == 1). - Transaction T3 annulée (ft3 == 0), car la valeur de z est modifié entre son read par T3 à la date 6 et son commit date 16, par T2 à la date 7. ### TM2PL - Transaction T1 bloqué (ft2 == 0) - Transaction T2 bloqué (ft2 == 0) - Transaction T3 bloqué (ft3 == 0) Il y a interblocages. ### Quelles seront les valeurs de variables affichées par la commande list ? #### TMPP ``` T_objets : ft1 1 ft3 0 ft2 0 x 0 y 0 z 0 ``` #### TMPC ``` T_objets : ft1 1 ft3 0 ft2 1 x 0 y 1 z 2 ``` #### TM2PL ``` T_objets : ft1 0 ft3 0 ft2 0 x 0 y 1 z 0 ``` ## Illustrer la limite de la propagation directe sur un scénario simple, interprété par le shell. ``` init TM2PL (x,0) (ft1,0) (ft2,0) (ft3,0) new T1 ; new T2 ; new T3 T1 write x 1 T2 read x T1 write x 2 T3 read x T1 write ft1 1 ; T1 commit T2 write ft2 1 ; T2 commit T3 write ft3 1 ; T3 commit ``` À la fin de ces transaction, à cause de la propagation directe, T2 et T3 n'aurons pas lu la même valeur de x, et cela peut causer des comportements inattendus. # Évaluation de protocoles ## Commenter les scénarios fournis Scénario 1 ``` Transaction t1 validée 0 unités de temps perdues 44 unités de temps attendues 26 unités de temps utiles Transaction t2 validée 0 unités de temps perdues 19 unités de temps attendues 31 unités de temps utiles Transaction t3 validée 0 unités de temps perdues 0 unités de temps attendues 33 unités de temps utiles Temps total : 70 Temps optimal : 33 Temps séquentiel : 90 ``` Scénario 2 ``` Transaction t1 validée 0 unités de temps perdues 0 unités de temps attendues 26 unités de temps utiles Transaction t2 validée 0 unités de temps perdues 0 unités de temps attendues 31 unités de temps utiles Transaction t3 annulée 33 unités de temps perdues 0 unités de temps attendues 0 unités de temps utiles Temps total : 33 Temps optimal : 33 Temps séquentiel : 90 ``` Scénario 3 ``` Transaction t1 validée 0 unités de temps perdues 0 unités de temps attendues 26 unités de temps utiles Transaction t2 validée 0 unités de temps perdues 0 unités de temps attendues 31 unités de temps utiles Transaction t3 validée 33 unités de temps perdues 0 unités de temps attendues 33 unités de temps utiles Temps total : 66 Temps optimal : 33 Temps séquentiel : 90 ``` Le scénario 2 est plus rapide que le scénario 1, puisque ses transactions n'attendent pas les autres, cependant la transaction T3 échoue. Le scénario 3 est plus rapide que le scénario 1, ceci est dû à l'utilsation de super-transactions, en effet la transaction T3 du scénario 2 est rejoué à la fin des transaction T1 et T2. ## Définir des scénarios permettant de caractériser les situations favorables à chacune des politiques TODO # Mise en œuvre des protocoles de contrôle de concurrence ## Indiquer (et justifier) pour chacun de ces protocoles ### A - optimiste, les modifications sont écrites sur la mémoire principale et "undo" si la transaction abort - l'algorithme est optimiste, il peut ne pas assurer la sérialisabilité - différée, les locks ne sont libérés qu'à la toute fin - Il y a risque d'interblocage - Il y a risque de rejet en cascade ### B - pessimiste, les modificatison des transactions sont effectuées dans une mémoire à part, et transférée vers la mémoire principale lors du commit. - l'algorithme est pessimiste, il assure la sérialisabilité - différée, puisque le protocole est pessimiste - Il n'y a pas de risque d'interblocage - Il n'y a pas risque de rejet en cascade