Grundsätzliches zum Recordlocking

Alle Themen rund um die Erstellung von Programmen
Antworten
satmax
Senior Member
Beiträge: 312
Registriert: 24. September 2015, 10:05
Wohnort: Biberbach, Austria
Kontaktdaten:

Grundsätzliches zum Recordlocking

Beitrag von satmax »

Ich möchte hier mal grundsätzlich über das Datenbank (Record) Locking diskutieren. Da geht es nicht (nur) um Windev.

Herbert schreibt in einem anderen Thread zb:
Will jemand anderes in derselben Adresse ändern ist so der Datensatz gesperrt und eine Meldung erscheint.
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.

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.

Herbert
Site Admin
Beiträge: 529
Registriert: 23. Februar 2010, 08:06
Wohnort: Langenthal, Schweiz
Kontaktdaten:

Re: Grundsätzliches zum Recordlocking

Beitrag von Herbert »

Danke für deine Gedanken.
Der Wunsch, dass ein Verhindern einer Aenderung in einem Record, wenn jemand anderes bereits änderungen vornimmt, ist naheliegend. Die Xbase-Systeme kennen das. So auch Windev. Selbst bei direktem Angebundensein an einen fremden SQL-Derver funktioniert das.
Ich erinnere mich an einen Vortrag von Steffen Piersig, wo er die Mechanismen erläuterte, die es dazu braucht, dass man vor allem kompatibel im Code bleibt (das berühmte Recordlocking). Derselbe Mechanismus verwendet auch Windev.
Und wie du richtig schreibst, bestimmt die Art der Erfassung und Mutation von Daten, was sein soll und was nicht. In meinem Beispiel sind das Daten von Sozialbezügerinnen und -bezügern, die Geld bekommen. So darf eben nur eine Person aufs Mal daran manipulieren.
Soweit ich weiss, ist es In Windev es so, dass ein Record-Locking keinen Lock auf die SQL-Tabelle auslöst, sondern nur innerhalb der direct access Software oder der HFSQL-Engine abgefangen und gegenüber der Applikation vermittelt wird.
Dein Gedankenansatz kann sehr wohl Sinn machen. Einerseits bist nahe an einem Protokollier-Tool, andererseits übernimmst du die Kontrolle bei mehrschichtigem Zugriff auf jeweils dieselben Records. Allerdings kann das ganz schön schwierig werden, je nach dem aus welchen weiteren Tabellen ein Auftrag zusammengestiefelt werden muss (Stichworte Lagerbestand, Preisgestaltung usw.).

Antworten