Hallo nochmal zum "Privat Thread"

Sperren über eine Benutzertransaktion hinaus:

Völlig einverstanden, eine Datenbanktransaktion darf nie länger als eine Benutzertransaktion sein, d.h. es dürfen keine Sperren gehalten werden beim EXFMT. Aber genau deshalb ist der Verzicht auf Commit riskant. Ist der Cursor updatebar, wird der letzte Satz festgehalten, es sei denn man macht einen Dummy update, oder schließt den Cursor. Unter Commit macht man vor dem EXFMT schnöderweise einen Rollback, (Transaktionsmonitore, wie CICS machen sowqas automatisch.

Das mit dem SELECT for Update stimmt leider nicht, da die Leseoperation sich keine ausreichende Sperre zum update holt, sondern nur soweit sperrt, dass andere nicht dürfen. Das heisst wenn zwei fast zeitgleich lesen, dann hakts beim Versuch des updates. Nun ist es gerade so, dass Sätze, die einen Schlüsselwert zum Hochzählen speichern, konkurrierend benötigt werden und da tritt der Lock Konflikt beim Versuch des Updates auf. Bei der umgekehrten Logik, wie von mir vorgeschlagen, Hat der erste sofort die volle Sperre und der zweite wartet die 3 Millisekunden bis der erste seine erhöhte Nummer gelesen hat und den Satz frei gibt.

Mir ist beim blossen lesen der SQL Reference das auch nicht so klar gewesen, geklingelt hat es dann, als Sperrkonflikte bei einer Keyverwaltung aufgetreten sind.

mfg

Dieter Bender