|
Das Problem besteht darin, daß "ältere" Änderungen durch zeitlich verschobene Zugriffe verloren gehen können:
Transaktion A Zeit Transaktion B
- -
lese Satz R t1 -
|
- t2 lese Satz R
|
ändere Satz R t3 -
|
- t4 ändere Satz R
- -
Lösung mittels Locking:
Transaktion A Zeit Transaktion B
- -
lese Satz R zum Ändern
(meldet X-Lock auf Satz R an) t1
| -
|
- t2
| lese Satz R zum Ändern
(möchte X-Lock auf Satz R)
|
ändere Satz R t3 wartet auf Freigabe von Satz R durch A
|
Synchpoint; Ende Transaktion
(gibt Satz R wieder frei) t4
| wartet auf Freigabe von Satz R durch A
|
- t5
| lese Satz R zum Ändern
(meldet X-Lock auf Satz R an)
- -
Mit dem Einlesen des Satzes R zum Zeitpunkt t1 wird dieser mit einem X Lock gesperrt. Dadurch werden alle weiteren Zugriffe (z.B. Leseanforderung zum Zeitpunkt t2) gesperrt. Erst nach Freigabe der Sperren (Zeitpunkt t4) kann der Datensatz weiter verwendet werden.
Verwendet man allerdings an Stelle der X Locks in obigem Beispiel S Locks so treten neue Probleme auf:
Transaktion A Zeit Transaktion B
- -
lese Satz R
(meldet S-Lock auf Satz R an) t1
| -
|
- t2
| lese Satz R
(meldet S-Lock auf Satz R an)
|
ändere Satz R
(möchte X-Lock auf Satz R) t3
| -
|
wartet auf Freigabe von Satz R durch B t4
| ändere Satz R
(möchte X-Lock auf Satz R)
|
wartet auf Freigabe von Satz R durch B t5 wartet auf Freigabe von Satz R durch A
|
wartet auf Freigabe von Satz R durch B wartet auf Freigabe von Satz R durch A
Da Transaktion A beim Lesen seine Änderungsabsicht noch nicht bekanntgibt, wird Transaktion B zum Zeitpunkt t2 der Lesezugriff nicht verwehrt. Die in der Folge angeforderten X Locks versetzen beide Transaktionen in den Wartezustand, da das von der gegnerischen Transaktion gesetzte S Lock kein X Lock zuläßt. Diese Situation bezeichnet man als Deadlock. Die Lösung dieses neuen Problems wird später erklärt.
|
