Herbert schreibt in einem anderen Thread zb:
Abgesehen davon dass so ein Locking unter MS SQL gar nicht möglich ist (während eines Locks wäre keine weitere Transaction möglich, DB Locks sollten immer nur während dem schreiben in der DB aktiv sein,...), kann man das für viele Fälle auch aus anderen Gründen so nicht verwenden. Beispiel Auftrag, ich füge zu einem Auftrag mehrer Artikel hinzu, da hilft der Lock des Auftrages nicht, die Tabelle Auftrag wird ja gar nicht verändert. Es werden ja nur Artikelpositionen hinzugefügt. Ich habe zB. Aufträge die mit 10 oder mehr anderen Tabellen verknüpft sind.Will jemand anderes in derselben Adresse ändern ist so der Datensatz gesperrt und eine Meldung erscheint.
Bei einer einfachen Adresse kann man mit einem Timestamp oder einer rowversion noch vernünftig arbeiten, aber auch da gibt es viele anderen Fälle wie wieder verschiedene Records gleichzeitig gelockt werden müssten. Zur Erinnerung, während eines locks kann keine Transaction aktiv sein.
Die Idee wäre nun, nicht einen Datensatz auf Record Ebene zu sperren und damit eben auch die ganze DB zu blockieren sondern einen ganzen Vorgang zur Bearbeitung sperren. Meine Grundidee wäre nun, eine eigene Tabelle anzulegen und darin die ganzen aktuell in Bearbeitung stehenden Vorgänge wie zB. einen Auftrag einzutragen.
Felder der Tabelle inProgress:
VorgangName, Vorgang_id, USER_ID, Station, TxtMSG, timestampAngelegt, timestampLastUpdate rowversion,...
Darin trage ich ein:
"auftrag", 4711,1,"PCXY","Text der eventuell auf den anderen Arbeitsstationen im Falle eines Zugriffs angezeigt werden kann, timestamp, rowversion....
TxtMSG könnte auch ein statischer Text sein.
Derjenige der einen Auftrag bearbeitet erstellt einen Eintrag in der Tabelle inProgress, solange der Vorgang in Bearbeitung ist wird der timestamp alle 15-60 Sekunden aktualisiert. Will nun ein zweiter User diesen Vorgang bearbeiten bekommt er den Text TxtMSG angezeigt. Ist der Timestamp älter wie diese 15-60 Sekunden (plus 1-3 Minuten Reserve, kann davon ausgegangen werden, dass die ursprüngliche Station den Datensatz nicht mehr in Bearbeitung hat sondern eventuell abgestürzt ist. Also kann die neue Station den Eintrag in der Tabelle inProgress übernehmen, mit eigenen Werte befüllen und den Timestamp automatisch aktualisieren.
Wird die Bearbeitung beendet, wird einfach der Record in der Tabelle inProgress wieder gelöscht. Der Vorgang kann nun wieder von allen bearbeitet werden.
Damit würde das eigentliche Locking in der DB entfallen und komplett von der Businesslogik in der Anwendung ersetzt werden.
Mich würde nun Eure Meinung dazu interessieren.