Satzsperren

Wenn mehrere Benutzer gleichzeitig versuchen, einen Datensatz zu aktualisieren, stellt das Datenbanksperrmodell sicher, dass die Aktualisierung jedes einzelnen Benutzers als Einheit durchgeführt wird. Zu beachten ist jedoch, dass jede neue Aktualisierung die vorherige Aktualisierung überschreibt.

Ein explizites (pessimistisches) Sperrmodell verhindert, dass ein unerwarteter Datenverlust eintritt. Außerdem steuert es den Arbeitsablauf, wenn mehrere Benutzer gleichzeitig Aktualisierungen durchführen.

Es können zwei Sperrmodelle verwendet werden:

Optimistische Sperre (Optimistic Locking)

Die optimistische Sperre ermöglicht mehreren Benutzern, einen Datensatz gleichzeitig anzuzeigen und zu versuchen, den Datensatz zu ändern. Allerdings ist nur der erste Benutzer in der Lage, seine Änderungen festzuschreiben. Ein Benutzer wird nicht darüber informiert, dass andere Benutzer ebenfalls versuchen, den Datensatz zu aktualisieren.

Die Änderungen des Datensatzes werden validiert, wenn der Datensatz festgeschrieben wird. Wenn ein anderer Benutzer den Datensatz bereits erfolgreich aktualisiert hat, werden andere Benutzer, die gleichzeitig Aktualisierungen vornehmen und versuchen, diese Änderungen zu übergeben, darüber informiert, dass ein Konflikt vorliegt.

Standardmäßig werden Datensätze, wenn sie in einer Clientanwendung von ClearQuest angezeigt werden, nicht gesperrt. Folglich sollte jeder Schemaentwurf, der einen einzelnen Standort oder eine replizierte Umgebung verwendet, dies berücksichtigen.

Die Datenintegrität wird dadurch sichergestellt, dass, wenn ein Benutzer auf Apply klickt, überprüft wird, ob ein anderer Benutzer den Datensatz aktualisiert und die Änderung während des noch laufenden Änderungsprozesses festgeschrieben hat. Ist das der Fall, können die Änderungen des erstgenannten Benutzers nicht in der Datenbank festgeschrieben werden, da dann einige der vom anderen Benutzer vorgenommenen Änderungen verloren gehen könnten. Der Benutzer, der versucht, seine Änderungen festzuschreiben, nachdem der Datensatz von einem anderen Benutzer aktualisiert wurde, empfängt eine Fehlernachricht, die besagt, dass die Änderungen nicht in der Datenbank festgeschrieben werden konnten.

In komplizierten Szenarios, die koordinierte Aktualisierungen mehrerer zusammengehöriger Datensätze umfassen, muss sichergestellt werden, dass dieses Verhalten keine Probleme verursacht. Da die optimistische Sperre (Optimistic Locking) für jeden Datensatz einzeln gültig ist, muss Ihre Anwendung sicherstellen, dass die Datensätze in der richtigen Reihenfolge aktualisiert und Fehler bei der Aktualisierung von untergeordneten Datensätzen behoben werden. Diese Fehler können auftreten, wenn ein anderer Benutzer versucht, einen untergeordneten Datensatz zu aktualisieren, nachdem Sie Ihre Aktion begonnen und bevor Sie Ihre Änderungen festgeschrieben haben. Ihr Schemaentwurf kann die Operation wiederholen oder den Fehler bestätigen und die Aktualisierung des übergeordneten Datensatzes aufheben oder die Aktualisierung des übergeordneten Datensatzes festschreiben, obwohl die Aktualisierung des untergeordneten Datensatzes fehlgeschlagen ist.

Ihr Schemaentwurf sollte in der Lage sein, Fälle zu bewältigen, in denen ein Datensatz geändert werden kann,
  • die Änderung jedoch fehlschlägt, weil der Datensatz während der Änderung von einem anderen Benutzer geändert wurde.
  • ein untergeordneter Datensatz ebenfalls geändert werden kann, die Änderung jedoch fehlschlägt, weil der untergeordnete Datensatz während der Änderung von einem anderen Benutzer geändert wurde.

Pessimistische Sperre (Pessimistic Locking)

Die pessimistische Sperre ist ein Verfahren, mit dem verhindert wird, dass mehrere Benutzer einen Datensatz bearbeiten können. Das Modell für die pessimistische Sperre erzwingt die sequenzielle Änderung von Datensätzen und verhindert deren gleichzeitige Aktualisierung. Sobald ein Benutzer beginnt, den Datensatz zu aktualisieren, belegt das Modell den Datensatz mit einer Sperre. Alle anderen Benutzer, die versuchen, diesen Datensatz zu aktualisieren, werden darüber informiert, dass ein anderer Benutzer bereits dabei ist, eine Aktualisierung durchzuführen, und werden gesperrt, so dass sie keine Änderung durchführen können. Wenn Benutzer den Datensatz gleichzeitig aktualisieren möchten, müssen sie warten, bis der erste Benutzer den Datensatz festgeschrieben hat, dann wird die Sperre für den Benutzer, der in der Reihenfolge der nächste ist, aufgehoben, und er kann neue Änderungen vornehmen. Dieses Modell beugt der Konfliktlösung vor, da es Konflikte bereits im Vorfeld verhindert. Aktualisierungen werden serialisiert, und jede nachfolgende Aktualisierung beginnt mit dem bereits aktualisierten Datensatz, der die Änderungen des vorherigen Benutzers enthält.

Es ist erforderlich, eine Sperre abzurufen, um andere Benutzer am Versuch, zu hindern, den Datensatz zu aktualisieren. Dieses Modell erfordert eine Strategie für die Verwaltung von Sperren, die folgende Aktionen beinhaltet:
  • die Sperre abrufen
  • alle Benutzer, die den Datensatz gleichzeitig aktualisieren möchten, darüber informieren, dass sie warten müssen, bis die Sperre aufgehoben ist
  • die Benutzer informieren, wenn die Sperre aufgehoben wurde
  • verlassene Sperren (z. B. bei Systemabstürzen oder wenn eine Aktualisierung nicht abgeschlossen wurde) aufheben

Zum Verwenden der pessimistischen Sperre von Datensätzen muss der Hook-Code den entsprechenden Satztypen hinzugefügt werden. Der Hook-Code muss für jeden Satztyp einer neuen Basisaktion (BASE) hinzugefügt werden. Sperren können mit Hook-Code, der als Alias eines Datensatz-Scripts implementiert wird, manuell entfernt werden. Sie können eine ClearQuest-Abfrage verwenden, um gesperrte Datensätze zu lokalisieren. Dabei wird nach Datensätzen gesucht, deren Feld "locked_by" Werte ungleich Null enthält. Die Spalte "locked_by" der Benutzerdatenbank ist eine Spalte mit einer Ganzzahl, in der die Anmelde-ID des Benutzers beim Sperren eines Datensatzes aufgezeichnet wird.

Das Modell der pessimistischen Sperre ist nützlich, wenn echte simultane Aktualisierungen nicht erforderlich sind und nachfolgende Aktualisierung verzögert werden können, bis eine vorhergende Aktualisierung abgeschlossen ist. Das bedeutet normalerweise, dass Aktualisierung in einem sehr kurzen Zeitintervall stattfinden. Aktualisierungen, die die Sperre für einen langen Zeitraum aufrechterhalten, hindern andere Benutzer daran, den Datensatz zu aktualisieren.


Feedback