Sperren über Schlüsselwert
Ereignisaktion - Kurzfassung
Zweck: Die Ereignisaktion kann in Ereignisbehandlungen eine Staffelung konkurrierender Prozesse in unterschiedlichen Transaktionen erreichen, indem eine per Schlüsselwert benannte Sperre geprüft und ggf. gesetzt wird.
Mit Hilfe der Sperren über Schlüsselwert-Ereignisaktion kann in Ereignisbehandlungen eine Staffelung konkurrierender Prozesse in unterschiedlichen Transaktionen gesteuert werden.
Beim Ausführen der Sperren über Schlüsselwert-Ereignisaktion wird geprüft, ob für den angegebenen Schlüsselwert serverseitig eine Sperre durch eine andere Transaktion registriert ist.
Liegt eine Sperre für den Schlüsselwert vor, wird die Ereignisverarbeitung (in der eigenen Transaktion) vorübergehend angehalten, bis die andere Transaktion beendet ist.
Liegt noch keine Sperre für den Schlüsselwert vor, wird eine Sperre registriert, sodass andere Transaktionen, die sich auf denselben Schlüsselwert beziehen, ggf. warten müssen, bis die eigene Transaktion beendet ist, deren Ereignisverarbeitung ohne Unterbrechung weiterläuft.
Falls mehrere Transaktionen die Sperren über Schlüsselwert-Ereignisaktion mit demselben Schlüsselwert ausführen, während für diesen bereits eine Sperre besteht, werden wartende Transaktionen nach dem Warteschlangen-Prinzip "Wer zuerst kommt, mahlt zuerst" (en.: "first come, first served") gestaffelt fortgesetzt.
Die Sperren über Schlüsselwert-Ereignisaktion wird typischerweise verwendet, um zu verhindern, dass unterschiedliche, nebenläufige Transaktionen versuchen, eine inhaltlich gleichwertige Aktion auszuführen, z. B. das Erstellen einer Entität für "denselben" Stammdatensatz.
Diese Möglichkeit sollte allerdings sparsam und in Verbindung immer mit einem geeigneten möglichst spezifischen Schlüsselwert genutzt werden, damit kein "Flaschenhals" in der Ereignisverarbeitung entsteht.
Was ist mit Deadlocks?
Sobald mehrere Schlüsselwerte im Spiel sind, kann es zu einem Deadlock zwischen zwei Transaktionen kommen, indem diese sich gegenseitig blockieren, weil sie wechselseitig aufeinander warten.
Beispiel:
Eine Ereignisbehandlung (I) beginnt mit einer Sperren über Schlüsselwert-Ereignisaktion für den Schlüsselwert "X" und startet danach eine langwierige Datenbankoperation (SQL-Abfrage ausführen).
Danach folgt eine weitere Sperren über Schlüsselwert-Ereignisaktion für den Schlüsselwert "O", bevor die Ergebnisse per Hinweis anzeigen gemeldet werden sollen.
Eine andere Ereignisbehandlung (II) beginnt mit einer Sperren über Schlüsselwert-Ereignisaktion für den Schlüsselwert "O".
Danach folgt eine weitere Sperren über Schlüsselwert-Ereignisaktion für den Schlüsselwert "X", bevor ein Rückgabewert per Hinweis anzeigen gemeldet werden soll.
Wenn zur Laufzeit zuerst die erste Ereignisbehandlung (I) ausgelöst wird und - während deren Datenbankoperation andauert - zusätzlich die zweite Ereignisbehandlung (II) anläuft, passiert folgendes:
(II) setzt sofort eine Sperre für den Schlüsselwert "O" und wartet dann auf die Aufhebung der von (I) veranlassten Sperre für den Schlüsselwert "X".
Sobald (I) die Datenbankoperation abschließt, droht ein Deadlock, weil (I) dann auf die Aufhebung der inzwischen von (II) veranlassten Sperre für den Schlüsselwert "O" warten muss, die wegen der Sperre für Schlüsselwert "X" bis zum Abschluss von (I) nicht zu erwarten ist. Damit ist der "Zirkel" perfekt.
Damit ein akuter Deadlock nicht beide Transaktionen unwiderruflich "ins Nirvana schickt", fängt Lobster Data Platform / Orchestration den drohenden Deadlock zur Laufzeit ab und löst beim Ausführen der Sperren über Schlüsselwert-Ereignisaktion, die den Kreis schließen würde, eine Fehlermeldung aus.
Die ausgelöste Fehlermeldung (Deadlock detected) benennt die beteiligten Schlüsselwerte und beendet eine der Transaktionen.
Die andere Transaktion wird daraufhin fortgesetzt werden.
Konfiguration
Die Ereignisbehandlung erwartet kein Bezugsobjekt. Ein vorliegendes Bezugsobjekt steht allerdings als Eingabewert für die Wert-Konfiguration im Parameter Schlüsselwert zur Verfügung.
Für den Parameter Schlüsselwert wird ein Textwert erwartet, der entweder per Direkteingabe (Standard) oder - nach einem Klick auf den kleinen grauen Pfeil links unten im Textfeld - über eine Wert-Konfiguration bereitgestellt werden kann.
Liefert eine Wert-Konfiguration zur Laufzeit keinen Textwert, wird das serverseitige String-Abbild des Rückgabewerts als Schlüsselwert verwendet.
Falls keine Eingabe bzw. Wert-Konfiguration vorliegt oder eine Wert-Konfiguration für den Schlüsselwert zur Laufzeit "Kein Wert" ($null) liefert, ist die Ereignisaktion wirkungslos.
Falls eine Wert-Konfiguration als Schlüsselwert eine Liste zurückgibt, die als einzigen Eintrag den Dynamischen Aufzählungswert für das Land "Frankreich" (FR) enthält, ist dies wirkungsgleich mit der Eingabe der Zeichenfolge "[FR]".
Die als Schlüsselwert übernommene Kennung wird beidseitig getrimmt, um den effektiven Schlüsselwert für die Sperre zu erzeugen.
Die Eingabe von randständigen Whitespace-Zeichen hat keine Auswirkung auf den effektiven Schlüsselwert. Zeichenfolgen wie "A51", "A51" oder "A51" adressieren effektiv immer den Schlüsselwert "A51".
Eine Sperrung findet nur statt, wenn die Zeichenfolge nach dem Trimmen mindestens ein Zeichen enthält.
Die als Schlüsselwert definierte Zeichenfolge wird unter Berücksichtigung der Groß-/Kleinschreibung verarbeitet.
Die Zeichenfolgen "eMail" und "Email" erzeugen unterschiedliche effektive Schlüsselwerte.
Beispiel
Einfaches Szenario für Experimente
►WICHTIG◄ Das folgende Szenario ist kein typischer Anwendungsfall aber gut geeignet, um den Effekt der Sperren über Schlüsselwert-Ereignisaktion mit geringem Aufwand im Experiment kennenzulernen. Es handelt sich ausdrücklich nicht um eine empfehlenswerte Vorgehensweise, um die beschrieben Aufgabenstellung zu lösen.
Ein Eigenes Aktionsevent (LOCK_FILE_FOR_APPEND) wird über ein Ribbon-Makro ausgelöst, das in das Ribbon verschiedener Views "eingehängt" werden kann.
Auf diesem Weg sollen berechtigte Benutzer die Möglichkeit erhalten, einen Texteintrag an eine serverseitig abgelegte Datei ihrer Wahl anzuhängen:
Im ersten Schritt wird vom Benutzer per Benutzereingabe-Wertauflöser der Name der Zieldatei abgefragt. Ob die Datei bereits existiert, oder beim anschließenden Schreibzugriff neu erstellt werden muss, soll dabei keine Rolle spielen.
Im zweiten Schritt wird der anzuhängende Text wiederum per Benutzereingabe-Wertauflöser abgefragt.
Anschließend wird die Datei aktualisiert.
Sobald ein Benutzer im ersten Schritt eine bestimmte Zieldatei benannt hat, sollen weitere Schreibzugriffe auf dieselbe Datei verhindert werden, bis die Aktualisierung der Datei abgeschlossen ist.
Für einen einfachen Test reicht es aus, zwei Views (ggf. auch zwei Instanzen derselben View) nebeneinander zu öffnen, die den Ribbon Button anbieten. Dann kann man innerhalb derselben Sitzung zwei nebenläufige Transaktion starten, in denen der Dateiname entweder übereinstimmend oder unterschiedlich gewählt werden kann.
Konfiguration:
Der folgende Screenshot rechts zeigt die Konfiguration für die einzige Ereignisbehandlung, die für die Demonstration benötigt wird.
|
Ein Eigenes Aktionsevent (LOCK_FILE_FOR_APPEND) dient als Auslösendes Ereignis. Der Datenkontext spielt für die Demonstration keine Rolle. Die Prüfende Regel ist hier als Rollenregel ausgeführt, um den Nutzerkreis einzuschränken. Die Aktionen bei bestandener Regel sollen ausgeführt werden, wenn ein berechtigter Benutzer das Auslösende Ereignis über das Ribbon ausgelöst hat:
►HINWEIS◄ Der eingegebene Text wird hier ungeprüft und direkt als Schlüsselwert genutzt, um eine Sperre unter dem Namen der adressierte Datei vorzunehmen bzw. um festzustellen, ob bereits eine Sperre vorliegt. Benennt der Benutzer per Benutzereingabe eine Datei, die bereits durch eine andauernde Transaktion gesperrt ist, wird die Ereignisverarbeitung angehalten, bis diese beendet wird. Das passiert nachdem der Eingabedialog geschlossen wurde und ohne weitere Rückmeldung außer dem Waiting Cursor.
|
|
Laufzeitbeispiel:
Die linke View zeigt eine Transaktion im zweiten Schritt (Texteingabe), nachdem eine Datei notepad für die Ausgabe benannt wurde.
In diesem Zustand wurde eine Sperre mit dem Schlüsselwert notepad für diese Transaktion eingerichtet.
Nach der Texteingabe und dem Klick auf OK wird die Eingabe gespeichert und die Transaktion endet. Damit wird die notepad-Sperre aufgehoben.
Die rechte View zeigt eine später gestartete Transaktion im ersten Schritt (Dateiauswahl), die versuchen soll, auf dieselbe Datei zuzugreifen wie die Transaktion links.
Beim Klick auf OK wird die Sperren über Schlüsselwert-Ereignisaktion ausgeführt, die angehalten wird, bis die Transaktion links endet. Erst nach dem Ende der linken Transaktion erscheint rechts der Dialog für die Texteingabe.
Wird vor dem Klick auf OK rechts ein anderer Dateiname (z. B. notepad2) eingegeben, der noch nicht als Schlüsselwert für eine aktive Sperre dient, dann erscheint der Dialog für die Texteingabe sofort.