232 lines
5.2 KiB
Markdown
232 lines
5.2 KiB
Markdown
|
## 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
|
||
|
|
|