Optimistische Sperren und Abhängigkeiten zwischen Tabellen...
-
Nachdem ich bislang überwiegend an Anwendungen mitgearbeitet habe, die pessimistische Sperrkonzepte verwendet haben, wollte ich mich nun intensiver mit optimistischen Sperrkonzepten vertraut machen (gerade auch weil einige DB-Schnittstellen inzwischen darauf ausgelegt sind).
Wie man eine Konfliktprüfung bei einem einzelnen Datensatz hinbekommt ist mit auch klar (u.a. die Variante mit einer Versionierung, z.B. mittels rowversion in SQL Server 2008 oder über Trigger).
In der Regel sind Daten aber meist über mehrere Tabellen verteilt (zumindest in den Anwendungen in denen ich bislang mitgearbeitet habe, ist das eher der Standardfall für die Bearbeitung, als die Ausnahme), beispielsweise das in einer Bearbeitenmaske auch gleich noch Zuordnungen zu anderen Datensätzen gepflegt werden.
In gewissen Fällen mag es unproblematisch sein, sofern wirklich nur unterschiedliche Datensätze parallel bearbeitet werden, in anderen muss sichergestellt sein, das keine Änderung auch in weiteren Datensätzen erfolgt ist.
1. Beispiel: In einer Maske für die Pflege von Personen werden auch noch seine Funktionen gepflegt. Wie nachfolgend grob beschrieben:
TblPerson (Id, Name, Nachname...)
TblPersonFunktion (IdPerson, Beschreibung...)In diesem Fall kann man wahrscheinlich damit leben, das gewisse Bearbeitungsüberschneidungen möglich sind (solange nur unterschiedliche Datensätze angepackt werden).
2. Beispiel: Es gibt aber vielleicht auch Abhängigkeiten in denen die Bearbeitung problematischer ist, z.B. Termine und Terminteilnehmer, wo eine terminliche Überlappung wenn nur mit Rückfrage möglich sein sollte:
TblTermin (Id, Beginn, Ende...)
TblTerminRessource (IdTermin, IdRessource...)Wie setzt man hier am besten eine optimistische Sperre um, da die Abhängigkeiten zwischen Datensätzen hier viel "freier" sind, und Konflikte auch durch neue Datensätze etc. entstehen können.
Meine bisherige Überlegung, wo ich mir aber nicht sicher bin, ob ich hier etwas übersehe, ist folgende:
a) Jeder Transaktion eine eindeutige Id zuzuweisen (Falls die DB dies direkt unterstützt über die DB-Features, sonst über einen neuen Datensatz in einer Tabelle), nennen wir dies im Folgenden TransaktionsId. Sowie einen Zeitstempel zu merken (Beginn der Transaktion).
b) Bei jedem Datensatz die TransaktionsId und einen Zeitstempel zu speichern.
c) Am Schluss ein Select über die Termine und Terminressourcen zu machen, die den Zeitraum des bearbeiteten Termines schneiden, und die seit dem Transaktionsbeginn von einer anderen als der aktuellen Transaktion geändert wurden. Wenn dies ein Treffer ergibt, wird die Transaktion zurückgesetzt.Wäre dies ausreichend, übersehe ich hier etwas, oder gibt es bessere Vorschläge?