DB2-Sperrmechanismen V6.0

Computer: Software & Programmierung SQL & Datenbank - Programmierung
1

Es gibt eine DB2-Tabelle, die zentral zur Vefügung steht und gleichermaßen von Batch wie auch von CICS-Programmen genutzt wird.

Im Buch DB2 von Norbert Denne 6.Auflage werden zwei Lösungsvorschläge vorgestellt, wie Deadlocksituationen bzw. verloren gegangene Updates z.B. durch einen ROLLBACK möglichst gering gehalten werden.

Zum einen wird der Weg eingeschlagen die Tabelle auf Zeilenebene explizit zu sperren, so dass kein anderes Programm an die Daten herankommt (weder lesend noch shreibend) und zum andereren wird durch eine zusätzliche Datenprüfung vor dem Update sichergestellt, dass der aktuell im Zugriff befindliche Wert auch tatsächlich noch mit dem in der Datenbank übereinstimmt.

Mein Problem ist, dass der zuerst beschriebene Vorschlag relativ Deadlock gefährdet ist, weil andere Applikationen warten müssen bis die Ressource wieder frei ist und der zweite Weg einen enormen Wartungsaufwand bedeutet, da er die Programmlogik in den meisten Routinen durcheinander werfen würde.

Vielleicht gibt es ja irgendwo jemanden, der sich schon einmal mit den Schwierigkeiten auseinader gesetzt hat und mir einige Tipps geben kann.

Ich sehe ein, dass die Problembeschreibung zahlreiche Lücken aufweist. Eine genauere Analyse kann ich gerne zur Verfügung stellen, wenn Bedarf besteht!

2

Hallo Nicole!

Hab mit sowas zwar auch nicht viel Erfahrung, aber ich denke mir dazu, dass einerseits nach dem Update ein Write-Lock auf den Datensatz bis zum Abschluß der Transaktion genügen würde.

Solange du die Anwendungen nicht synchronisierst kannst du sowieso nicht sichersein ob die anderen vor oder nach dem Update auf die Daten zugreifen.

Um Deadlocks auszuschließen müßtest du nach jedem einzelnen Update die Transaktion abschließen, dann kann IMHO nichts mehr passieren. Ob das möglich bzw. sinnvoll ist hängt von der Anwendung ab.

Grüße, Robert

3

Hallo,
normalerweise werden Programme nicht so geschrieben, daß sie auf den Daten sitzen bleiben. Es ist üblich, die Daten in die Maske (CICS) zu holen und dann sofort wieder freizugeben. Nach der Eingabe der neuen Daten erfolgt wieder eine Sperrung für das Update. Hier ist dann der Vergleich sinnvoll, ob die Daten noch aktuell sind. Meist handelt es sich aber bei DB2-CICS-Datenbanken um Milionen von Sätzen, so daß die Wahrscheinlichkeit einer zwischenzeitlichen Änderung doch sehr gering ist.
Soweit ich weiß gibt es aber in der SQLCA eine Variable, mit der man zwischenzeitliche Änderungen einfach abfragen kann, sollte also kein Problem sein.
Tilo