AWS Der Mainframe Modernization Service (Managed Runtime Environment Experience) steht Neukunden nicht mehr zur Verfügung. Funktionen, die dem AWS Mainframe Modernization Service (Managed Runtime Environment-Erfahrung) ähneln, finden Sie unter AWS Mainframe Modernization Service (Self-Managed Experience). Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Änderung der Verfügbarkeit von [AWS Mainframe Modernization](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Fehler zur Fehlerbehebung: Beim Warten auf die Entsperrung des Datensatznamens wurde eine Zeitüberschreitung überschritten
Auf dieser Seite wird beschrieben, wie Sie Ihren Fehler beheben können, wenn Sie feststellen, dass eine andere Anwendung in einer Umgebung einen gemeinsam genutzten Datensatz sperrt.
+ Engine: AWS Transformation für Mainframe
+ Komponente: Blusam
Wenn Sie diesen Fehler in den CloudWatch Amazon-Protokollen für eine AWS Mainframe-Modernisierungsanwendung sehen, die die AWS Transform for Mainframe-Engine verwendet und in einer Umgebung mit dem Hochverfügbarkeitsmuster ausgeführt wird, deutet dies darauf hin, dass eine andere Anwendung einen gemeinsam genutzten Datensatz gesperrt hat. In der Regel tritt diese Situation auf, wenn die andere Anwendung abstürzt oder auf andere Weise ausfällt und die Sperre nicht aufgehoben wird.
Suchen Sie nach einer fehlgeschlagenen Anwendung und überprüfen Sie, ob sie denselben Datensatz verwendet, der in der Fehlermeldung erwähnt wurde. Prüfen Sie, ob die Anwendung in einer Laufzeitumgebung mit dem Hochverfügbarkeitsmuster ausgeführt wird. Die Anwendung, die die Timeout-Ausnahme ausgelöst hat, kann den Vorgang nicht fortsetzen und zeigt den `Failed` Status an.
## Häufige Ursache
Die Anwendung `example-app-1` versucht, einen Datensatz `example-record-1` für einen Schreibvorgang zu sperren. Durch diesen Vorgang wird sowohl eine Sperre für den Datensatz`example-dataset-1`, der Eigentümer ist`example-record-1`, als auch eine Sperre für sich `example-record-1` selbst erstellt. Jetzt versucht eine andere Anwendung`example-app-2`,, denselben Datensatz zu sperren`example-record-1`. Der Datensatz und der Datensatz sind bereits gesperrt, `example-app-2` wartet also darauf, dass die Sperre aufgehoben wird. Bei einem `example-app-1` Absturz besteht die Sperre für die Datenmenge `example-dataset-1` immer noch, was `example-app-2` dazu führt, dass der Schreibversuch abgebrochen und eine Timeout-Ausnahme ausgelöst wird. Diese Deadlock-Situation verhindert, dass alle Anwendungen die Verbindung erreichen. `example-dataset-1`
## Auflösung
Um die Situation sofort zu lösen, können Sie das Aufheben der Sperre erzwingen. Um zu verhindern, dass eine ähnliche Situation in future auftritt, können Sie zwei Parameter konfigurieren, die den Blusam auto Reparaturmechanismus steuern.
## Erzwingen Sie das Lösen des Schlosses
Der Blusam Lockmanager verwendet Amazon ElastiCache (Redis OSS), um gemeinsame Sperren zwischen Anwendungen bereitzustellen. Verwenden Sie das Redis-CLI-Hilfsprogramm ElastiCache, um Sperren aufzuheben. Sie können eine einzelne Datensatzsperre nicht löschen. Sie müssen alle Sperren aus der Datenmenge entfernen, die der Eigentümer ist. Führen Sie folgende Schritte aus:
1. Stellen Sie ElastiCache mit dem folgenden Befehl eine Connect zu Ihrem her:
```
redis-cli -h {{hostname}} -p {{port}}
```
Sie finden die Details zu Ihrem ElastiCache in der ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Geben Sie Ihr Passwort ein.
1. Geben Sie den Befehl, den Sie ausführen möchten, wie folgt ein:
[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/m2/latest/userguide/ba-blusam-timeout.html)
## Konfigurieren Sie den Blusam auto Reparaturmechanismus
Der Blusam Schlossmanager enthält einen auto Reparaturmechanismus, um Deadlocks bei Datensätzen oder Datensätzen zu verhindern. Sie können die folgenden Parameter in der Anwendungsdefinition (`application-main.yml`) anpassen, um den auto Reparaturmechanismus zu konfigurieren:
+ `locksDeadTime`: bezieht sich auf die maximale Zeit, für die eine Anwendung eine Sperre aufrechterhalten kann. Nach Ablauf dieser Zeit wird die Sperre für abgelaufen erklärt und sofort aufgehoben. Der `locksDeadTime` Wert wird in Millisekunden angegeben und der Standardwert ist 1000.
+ `locksCheck`: definiert die Lock-Manager-Strategie zur Überprüfung von Blusam Sperren. Alle Blusam Sperren ElastiCache sind mit einem Zeitstempel versehen und haben eine Ablaufzeit. Der `locksCheck` Parameterwert bestimmt, ob abgelaufene Sperren entfernt werden.
+ `off`: Es wird zu keinem Zeitpunkt eine Prüfung ausgeführt. Es können Deadlocks auftreten. (Nicht empfohlen)
+ `reboot`: Prüfungen werden ausgeführt, wenn eine AWS Mainframe-Modernisierungs-Anwendungsinstanz, die in einer AWS Mainframe-Modernisierungs-Laufzeitumgebung ausgeführt wird, gestartet oder neu gestartet wird. Alle abgelaufenen Sperren werden sofort aufgehoben. (Standard)
+ `timeout`: Prüfungen werden ausgeführt, wenn eine AWS Mainframe-Modernisierungs-Anwendungsinstanz, die in einer AWS Mainframe-Modernisierungs-Laufzeitumgebung ausgeführt wird, gestartet oder neu gestartet wird oder wenn beim Versuch, einen Datensatz zu sperren, ein Timeout abläuft. Abgelaufene Sperren werden sofort freigegeben.
Weitere Informationen zur Anwendungsdefinition für eine AWS Transform for Mainframe-Anwendung finden Sie unter[AWS Beispiel für eine Transformation für eine Mainframe-Anwendungsdefinition](applications-m2-definition.md#applications-m2-definition-ba).
## BlusamSperren-Manager
Im Kontext einer Laufzeitumgebung für die AWS Mainframe-Modernisierung, die das Hochverfügbarkeitsmuster verwendet, kann eine AWS Transform for Mainframe-Anwendung mehrfach eingesetzt werden. Bei Anwendungen, die Blusam Datensätze verarbeiten, können Probleme beim gleichzeitigen Zugriff auftreten. Der Blusam Sperrmanager gewährleistet die Datenintegrität und verwaltet den Lese- und Schreibzugriff auf Datensätze und Datensätze, indem er gemeinsame Sperren zwischen Anwendungen bereitstellt, die diese verwenden ElastiCache. Dieser Mechanismus ermöglicht es mehr als einer Anwendung, den Datensatz gleichzeitig zu lesen, und stellt sicher, dass jeweils nur eine Anwendung den Datensatz schreibt.
### Sperren schreiben
Um einen bestimmten Datensatz zu aktualisieren oder zu löschen, muss die Anwendung zuerst die Datenmenge sperren, der der Datensatz gehört, und dann den Datensatz selbst sperren. Wenn der Datensatz gesperrt ist, wird die Datensatzsperre aufgehoben, und andere Datensätze aus demselben Datensatz können verwendet werden. Wenn der Aktualisierungs- oder Löschvorgang abgeschlossen ist, wird die Sperre für den Datensatz aufgehoben. Es kann jeweils nur eine Anwendung den Datensatz aktualisieren, wodurch andere Anwendungen entweder am Lesen oder Schreiben gehindert werden, bis die Sperre aufgehoben wird, sofern die definierte Anwendungsrichtlinie das Warten auf die Freigabe zulässt.
### Sperren lesen
Solange für den Datensatz oder die Datenmenge keine Schreibsperre gilt, können mehrere Anwendungen dieselben Datensätze gleichzeitig lesen. Um einen Datensatz für einen Schreibvorgang zu sperren, müssen alle Lesesperren aufgehoben werden.
**Anmerkung**
Der Blusam Sperrmanager verarbeitet den Zugriff von mehreren Threads in einer bestimmten Anwendung mithilfe desselben Sperrmechanismus.