Anonym.
Frage:
Wie kann ich bei einem SELECT folgendes erreichen:
a) dieser Satz soll gelockt werden
b) dieser Satz kann dann weder geändert noch angeschaut werden ?
a) dieser Satz soll gelockt werden
SELECT/FETCH … FOR UPDATE OF oder SELECT … WITH RR/RS (Isolation Level). Falls jedoch LOCKSIZE not = ROW wird mehr als ein Datensatz gelockt (normalerweise ganze Page).
b) dieser Satz kann dann weder geändert ……..
ja sichergestellt durch a)
b) ……..noch angeschaut werden ?
Nein, Lesen mit WITH UR ist immer möglich. Sonst je nach Implementation in a) (Stichwort USE AND KEEP EXCLUSIVE LOCKS) und Lock mode compatibility (siehe DB2 V8 Admin Guide http://publib.boulder.ibm.com/epubs/pdf/dsnagj15.pdf)
Ausprobieren kannst du es sonst mit DB2I/SPUFI (AUTOCOMMIT = NO)…
Danke für die ersten Antworten.
Zusatzfrage: Wenn ich will, dass der gelockte Satz in diesem FAlle auch nicht angezeigt werden kann. Geht dies auch ?
…auch nicht angezeigt werden kann
Will heissen?
In einer ONLINE-Funktion soll der Satz, der aktuell für einen UPDATE gesperrt ist und damit wahrscheinlich auch verändert wird, nicht angzeigt werden (ist ja kurz darauf nicht mehr aktuell). Hier handelt es sich um einen lesenden Zugriff.
Dies steht so in einer Vorgabe, die man umsetzen soll. Es soll eine Meldung kommen: "Satz wird gerade bearbeitet".
noch zu a)
FOR UPDATE ist grundsätzlich nur bei einem Cursor möglich ?
Dies geht nicht! Entweder wird der zweite lesende Prozess ge-queued (Warteschlange bis Commit/Rollback von Prozess 1 und Locks aufgehoben) oder er liest mit WITH UR (uncommited data – dirty read) und kann Daten trotz Locks lesen.
Lies mal den nachfolgenden Artikel über die DB2 Concurrency Mechanismen: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0406whitlark/
Ja, FOR UPDATE geht nur bei Cursor-Verarbeitung. Gibt bei singleton select einen pre-compile Fehler.
Weiter empfehle ich dir Vorgaben und Anforderungen immer kritisch zu hinterfragen! Lass dir mal den Use Case für "Datensatz wird gerade bearbeitet." erläutern…
Hallo,
wenn eine Row geändert werden soll, so sollte grundsätzlich bereits beim Lesen ein höherwertiger Lock verwendet werden (U- oder X).
Das kann erreicht werden, indem beim Lesen die FOR UPDATE- Clause verwendet wird, dadurch werden U-Locks benutzt. Allerdings isolieren sich damit nur die Transaktionen, die parallel mit FOR UPDATE die gleiche Row lesen. Einfache Selects sind weiterhin möglich, da die Row ja hier noch konsistent ist. Sollen sämtliche Lesezugriffe auf diese Row verhindert werden, so ist das über die Klausel WITH RR USE AND KEEP EXCLUSIVE LOCKS möglich. Dann wird die Row bereits beim Lesen mit einem X-Lock gesperrt. Wenn es in der Transaktion/Programm häufig oder sogar immer zu einem Update/Delete kommt ist das sogar besser, da dann keine Lock-Promotion von U nach X notwendig ist.
Wie schon gesagt wurde gibt es aber keine Möglichkeit über eine vorhandene Sperre informiert zu werden. Wenn ein SQL auf eine gesperrte Row trifft, so kommt es zur Lock-Suspension, d. h. es wird gewartet bis die vorhandene Sperre aufgehoben wird (Commit). Falls das nicht in einer im DB2 definierten Zeit passiert, kommt es zu einem TIMEOUT (-911 oder -913).
MfG Rolf
Hi 7up,
wenn die Vorgabe an der Stelle mit der Meldung "Satz ist in Bearbeitung" keinen Spielraum zulässt, dann mußt Du wohl eine applikatorische Lösung anstreben.
Soll heißen Wenn Du den Satz anzeigst setzt du ein Kennzeichen ‚In Bearbeitung‘
Und anzeigen darfst du nur Sätze, die dieses Flag nicht gesetzt haben.
Ist ein wenig umständlich (und denk auch an die Fälle, wenn das Flag gesetzt wird und dann der Rechner abschmiert –> solche Sätze wirst Du ohne eine spezialfunktion nie mehr sehen…) aber es sollte funktionieren
undimmer dran denken: Wer zahlt bestimmt 😎
Gruß auch ans forum Perixx
You must be logged in to reply to this topic.
