Sperren von Einheiten mit ORDA

Automatisch übersetzt von Deepl

Die ORDA-Serie geht weiter! In diesem Blogbeitrag sehen wir uns an , wie Sie Sperren in Ihren Datenbanken mit ORDA-Konzepten verwenden können! Es ist nicht ungewöhnlich, dass man Konflikte bewältigen muss , die auftreten können, wenn mehrere Benutzer oder Prozesse dieselben Datensätze gleichzeitig laden und/oder zu ändern versuchen. Das Sperren von Datensätzen ist eine Methode, die in relationalen Datenbanken verwendet wird, um inkonsistente Aktualisierungen von Daten zu vermeiden.

ORDA bietet einen optimistischen Sperrmodus zusätzlich zu dem, den Sie bereits kennen (pessimistisches Sperren).

Beispiel: Verwendung von pessimistischem Locking mit ORDA

Different locking modes

REKORDE UND EINTRAGUNGEN

Zur Erinnerung: Ein Datensatz ist ein physischer Datensatz in der Datenbank, auf den über eine Entität zugegriffen wird. Eine Entität ist ein Verweis auf einen Datensatz (siehe Abschnitt Entität im Glossar). Datensätze werden über Entitäten gesperrt und entsperrt.

Optimistisches Sperren

Beim optimistischen Sperren wird ein Datensatz vor dem Speichern daraufhin überprüft, ob andere Prozesse ihn seit dem Laden in eine Entität verändert haben. Der Vorteil ist, dass der Datensatz nur während der Speichermethode gesperrt wird.

Optimistisches Sperren stützt sich auf den Stempel der Datensätze. Jeder Datensatz hat einen internen Stempel, der jedes Mal, wenn der Datensatz in der Datenbank gespeichert wird, automatisch inkrementiert wird. Wenn ein Datensatz aktualisiert wurde, seit Sie eine Entität geladen haben, geben die Methoden save(), drop() und lock() einen bestimmten Statuscode zurück, der anzeigt, dass sich der Stempel geändert hat. Sie müssen dann entscheiden, wie Sie mit diesem Konflikt umgehen wollen.

Standardmäßig arbeitet ORDA mit optimistischem Locking, aber auch pessimistisches Locking ist möglich.

BEISPIEL

C_OBJECT($employee;$statusSave)

// Get the first employee whose last name is "Wates"
$employee :=ds.Employee.query("lastName=:1"; "Wates").first()

If ($employee#Null)
// Set name to "Mac Arthur"
$employee .lastName:="Mac Arthur"
// Mitarbeiter speichern
$statusSave :=$employee.save()
// Test if the save is successful
If ($statusSave.success)
ALERT ("Erfolgreich gespeichert!")
End if
End if
// Der Datensatz in der Datenbank wurde aktualisiert

Ich bin mir sicher, dass Sie gerne mehr über optimistisches Sperren erfahren möchten. Ein weiterer Blog-Beitrag, der sich ganz diesem Konzept widmet, folgt in Kürze. Bleiben Sie dran!

Pessimistic locking

Im pessimistischen Sperrmodus werden Datensätze beim Lesen gesperrt, damit andere Prozesse sie nicht aktualisieren können. Dadurch wird sichergestellt, dass ein geänderter Datensatz auf Kosten der Sperrung von Datensätzen für andere Benutzer geschrieben werden kann. Der Datensatz ist auch dann gesperrt, wenn kein konkurrierender Zugriff stattfindet.

Bei der pessimistischen Sperrung müssen Sie Datensätze vor der Aktualisierung sperren und nach der Aktualisierung wieder entsperren . Solange ein Datensatz gesperrt ist, schlägt das Speichern/Löschen/Sperren des Datensatzes in anderen Prozessen fehl, bis er von dem Prozess, der ihn gesperrt hat, wieder freigegeben wird.

Um eine Entität zu sperren, verwenden Sie die lock() -Methode und die unlock() -Methode, um sie zu entsperren.

Das „klassische“ 4D verwendet pessimistisches Locking.

BEISPIEL

C_OBJECT($employee;$statusLock;$statusSave;$statusUnLock)

// Get the first employee whose last name is "Wates"
$employee :=ds.Employee.query("lastName=:1"; "Wates").first()

If ($employee#Null)
$statusLock :=$employee.lock() // Lock the entity
// The entity has been successfully locked
If ($statusLock.success)
$employee .lastName:="Mac Arthur" // Set name to "Mac Arthur"
// Save employee-No need to check the status because the entity is locked
$statusSave :=$employee.save()
// Unlock entity, so other processes will be able to save/drop/lock it
$statusUnLock :=$employee.unlock()
End if
End if
// The record in the database has been updated

Haben Siekeine Angst, dass Sie vergessen, einen Datensatz zu entsperren. ORDA wird ihn automatisch entsperren, wenn es keine weiteren Referenzen auf die Entität gibt, die ihn gesperrt hat.

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert ist seit 2017 als Product Owner im 4D Produktteam tätig. Als Product Owner ist sie für das Schreiben der User Stories und deren Umsetzung in funktionale Spezifikationen zuständig. Ihre Aufgabe ist es auch, sicherzustellen, dass die Implementierung der Funktionen den Anforderungen des Kunden entspricht. Marie-Sophie ist Absolventin der ESIGELEC Ingenieurschule und begann ihre Karriere als Ingenieurin bei IBM im Jahr 1995. Sie nahm an verschiedenen Projekten teil (Wartungs- oder Build-Projekte) und arbeitete als Cobol-Entwicklerin. Dann arbeitete sie als UML-Designerin und Java-Entwicklerin. In letzter Zeit bestand ihre Hauptaufgabe darin, funktionale Anforderungen zu analysieren und zu schreiben sowie Geschäfts- und Entwicklungsteams zu koordinieren.