Sperren von Datensätzen

Question

Ich arbeite an einer Anwendung, bei der viele Mitarbeiter sich im System anmelden können, um Kundenbeschwerden zu lösen. Wenn ein Mitarbeiter auf die Schaltfläche "Start" für die Beschwerde klickt, sollte der Datensatz eingefroren werden. Mit eingefroren meine ich, dass er auf dem Bildschirm anderer Mitarbeiter nicht angezeigt werden sollte (wenn der Bildschirm auf ihren Geräten mit Ajax aktualisiert wird). Außerdem sollte er nur für eine bestimmte Zeitdauer nicht angezeigt werden. Wenn der Mitarbeiter innerhalb weniger Minuten nicht auf die Beschwerde reagiert, sollte sie wieder in der Warteschlange der Beschwerden erscheinen.

Wie verwalte ich diese Zeitdauer? Ich habe einen Ansatz, bei dem, wenn der Benutzer auf "Start" klickt, könnte ich dieses Element im Cache-Objekt speichern und es ist nur gültig, bis sein Ablaufdatum erreicht ist. Dann, wenn der Bildschirm anderer Mitarbeiter aktualisiert wird, zeige ich nur diejenigen Elemente, die nicht bearbeitet wurden und nicht im Cache vorhanden sind. Wenn es im Cache vorhanden ist, bedeutet das, dass es von jemandem bearbeitet wird. Bin ich auf dem richtigen Weg? Oder gibt es einen besseren Weg, das zu tun?

Answer 1

Der einfachste Weg, dies zu tun, besteht darin, eine Spalte namens "RecordStatus" oder so etwas zu haben, die auf einen speziellen Wert gesetzt werden kann, um anzuzeigen, dass sie immer noch erstellt oder geändert wird.

Dies zwingt Sie dazu, alle Ihre Abfragen so zu ändern, dass Datensätze mit diesem Status explizit ausgeschlossen werden, aber langfristig funktioniert es besser und ist zuverlässiger als jede Art von Datenbank- oder Anwendungsebene logische Sperren.

Answer 2

Eine Möglichkeit könnte sein, eine 'Lock'-Spalte in der Datenbank zu haben, die eine DateTime-Spalte ist.

Wenn ein Benutzer auf 'Start' klickt, merken Sie sich die Zeit in dieser Spalte.

Beim Abrufen von Datensätzen zur Anzeige filtern Sie alle Datensätze heraus, die einen nicht-null-Wert in der Lock-Spalte haben oder deren Wert in der Lock-Spalte von mindestens x Minuten alt ist (was Sie mit Mathematik auf der GetDate()-Funktion berechnen können).

Answer 3

Wir haben dies in meinem Unternehmen in zwei Situationen unabhängig voneinander gelöst, indem wir einige Variationen auf einem "Record Lock" DB Record verwendet haben. In einem System wird der Sperr-Record erstellt, wenn der Record als neues Element in die "Queue" eintritt; in dem anderen wird der Sperr-Record erstellt, wenn ein Benutzer einen Record aus der Queue abholt.

Wie auch immer man es betrachtet, sobald die Software eines Benutzers einen Queue-Record für die Arbeit öffnet, sollte ein Sperr-Record in der DB vorhanden sein, der einige eindeutige Identifizierungsinformationen über den Benutzer enthält, die in ihn geschrieben wurden. Es sollte eindeutig für den gesperrten Record sein und möglicherweise den Sperr-Level identifizieren (was bedeutet, dass zwei Sperrungen des gleichen Levels nicht auf dem gleichen Record existieren können) und den Benutzer, der den Record geöffnet hat, als "Besitzer" für den Zweck der Änderungen kennzeichnen. Dieser Sperr-Record sollte so lange bestehen, wie der Benutzer den Record in seiner Software geöffnet hat.

Die Möglichkeit, Sperrungen zu "brechen", kann einfach durch Neu-Zuweisung der Sperre an einen anderen Benutzer erreicht werden, zusammen mit regelmäßigem Abfragen des Sperr-Objekts durch die Software des original sperrenden Benutzers; wenn der Benutzer zu einem beliebigen Zeitpunkt nicht mehr der Besitzer ist, wurde die Sperre "gebrochen" und der Benutzer hat die Möglichkeit, die Sperre erneut zu erlangen (damit die Sperre des anderen Benutzers gebrochen wird) oder einfach weiterzumachen.

Sollte die Software des Benutzers abstürzen, wird er dennoch eine Sperre auf dem Record besitzen. Es kann auch vorkommen, dass die Operation zum Entfernen der Sperre fehlschlägt (dies kann in Situationen passieren, wo die echten Daten in einer anderen DB sind und man keine universelle Transaktion durchsetzen kann). In einem solchen Fall benötigen Sie einen Mechanismus, um "verwaiste" Sperren zu entfernen oder den Benutzer dazu zu zwingen, sie zu entfernen. Wenn die gesperrten Elemente zeitkritisch sind, müssen mehrere redundante Ebenen der Sperr-Entfernung entworfen werden (vielleicht ein Zeit-Job, der einmal pro Minute jede Sperre entfernt, die älter als X Minuten ist oder die als "verwaist" bekannt ist, weil dieser Benutzer nicht mehr eingeloggt ist).