Die folgenden Sperrstrategien sind verfügbar: PESSIMISTIC (pessimistisch), OPTIMISTIC (optimistisch) und NONE (Ohne).
Bei der Auswahl einer Sperrstrategie müssen Sie Aspekte wie den Prozentsatz der einzelnen Typen von Operationen, die potenzielle
Verwendung eines Loaders usw. berücksichtigen.
Sperren werden über Transaktionen gebunden.
Sie können die folgenden Sperreinstellungen angeben:
- Keine Sperren: Die Ausführung ohne Sperren ist die schnellste.
Wenn Sie schreibgeschützte Daten verwenden, benötigen Sie möglicherweise keine Sperren.
- Pessimistisches Sperren: Es werden Sperren für Einträge angefordert, die so lange gehalten werden, bis die
Transaktion festgeschrieben wird.
Diese Sperrstrategie bietet eine gute Konsistenz, geht aber zu Lasten des Durchsatzes.
- Optimistisches Sperren: Erstellt eine Vorher-Kopie jedes Datensatzes, den die Transaktion berührt, und vergleicht diese mit den aktuellen
Eintragswerten, wenn die Transaktion festgeschrieben wird.
Wenn die Vorher-Kopie und der Eintragswert nicht übereinstimmen, wird die Transaktion rückgängig gemacht.
Es werden keine Sperren bis zur Festschreibungszeit gehalten.
Diese Sperrstrategie unterstützt einen besseren gemeinsamen Zugriff als die pessimistische Strategie, birgt aber
das Risiko von Transaktions-Rollbacks und Speicherkosten für die zusätzliche Kopie des Eintrags.
Legen Sie die Sperrstrategie in der BackingMap fest. Es ist nicht möglich, die Sperrstrategie für jede einzelne Transaktion zu ändern.
Im Folgenden sehen Sie ein Beispiel-XML-Snippet, das veranschaulicht, wie der Sperrmodus in einer Map über die XML-Datei festgelegt wird,
und in dem davon ausgegangen wird, dass
cc der Namespace für
objectgrid/config ist:
<cc:backingMap name="RuntimeLifespan" lockStrategy="PESSIMISTIC" />
Pessimistisches Sperren
Verwenden
Sie die pessimistische Sperrstrategie für Maps mit Lese-/Schreibzugriff, wenn keine anderen
Sperrstrategien möglich sind.
Wenn eine ObjectGrid-Map für die Verwendung der
pessimistischen Sperrstrategie
konfiguriert ist, wird eine pessimistische Transaktionssperre für einen Map-Eintrag angefordert, wenn eine Transaktion
den Eintrag zum ersten Mal aus der BackingMap abruft. Die pessimistische Sperre wird so lange gehalten, bis die Anwendung
die Transaktion abschließt.
Gewöhnlich wird die pessimistische Sperrstrategie in den folgenden Situationen verwendet:
- Die BackingMap ist mit oder ohne Loader (Ladeprogramm) konfiguriert, und es sind keine Versionsinformationen verfügbar.
- Die BackingMap wird direkt von einer Anwendung verwendet, die Hilfe von
eXtreme Scale für die Steuerung des gemeinsamen Zugriffs benötigt.
- Es sind Versionsinformationen verfügbar, aber Aktualisierungstransaktionen für die Einträge in der BackingMap
lösen häufig Kollisionen aus, was zu Fehlern bei der optimistische Aktualisierung führt.
Da die pessimistische Sperrstrategie die größten Auswirkungen auf Leistung und Skalierbarkeit hat, sollte diese
Strategie nur für Maps mit Lese-/Schreibzugriff verwendet werden, wenn keine anderen Sperrstrategien angewendet werden können, z. B.,
wenn häufig Fehler bei der optimistischen Aktualisierung auftreten oder wenn die Wiederherstellung nach einem Fehler bei einer
optimistischen Aktualisierung nur schwer für eine Anwendung durchzuführen ist.
Optimistisches Sperren
Bei der
optimistischen Sperrstrategie wird davon ausgegangen, dass zwei gleichzeitig ausgeführte Transaktionen niemals
versuchen, denselben Map-Eintrag zu aktualisieren.
Aufgrund dieser Annahme müssen die Sperren nicht für den gesamte Lebenszyklus der Transaktion gehalten werden,
da es unwahrscheinlich ist, dass mehrere Transaktionen einen Map-Eintrag gleichzeitig aktualisieren.
Die optimistische Sperrstrategie wird gewöhnlich in den folgenden Situationen verwendet:
- Eine BackingMap ist mit oder ohne Loader (Ladeprogramm) konfiguriert, und es sind Versionsinformationen verfügbar.
- Es werden hauptsächlich nur Transaktionen für eine BackingMap ausgeführt, die Leseoperationen durchführen.
Einfüge-, Aktualisierungs- und Entfernungsoperationen für Map-Einträge finden in der BackingMap nur selten statt.
- Eine BackingMap wird häufiger eingefügt, aktualisiert oder entfernt, als sie gelesen wird, aber es finden nur selten
Kollisionen zwischen den Transaktionen statt, die sich auf denselben Map-Eintrag beziehen.
Wie bei der pessimistischen Sperrstrategie bestimmen die Methoden in der Schnittstelle "ObjectMap", wie
eXtreme Scale automatisch versucht, eine Sperre für den Map-Eintrag anzufordern, auf den
zugegriffen wird.
Es bestehen jedoch die folgenden Unterschiede zwischen der pessimistischen und der optimistischen Sperrstrategie:
- Wie bei der pessimistischen Sperrstrategie wird bei der optimistischen Sperrstrategie beim Aufruf der Methoden
"get" und "getAll" eine S-Sperre angefordert.
Beim optimistischen Sperren wird die S-Sperre jedoch nicht bis zum Abschluss der Transaktion gehalten.
Stattdessen wird die S-Sperre freigegeben, bevor die Methode zur Anwendung zurückkehrt.
Die Anforderung der Sperre hat den Zweck, dass eXtreme Scale sicherstellen kann,
dass nur festgeschriebene Daten von anderen Transaktionen für die aktuelle Transaktion sichtbar sind.
Nachdem eXtreme Scale sichergestellt hat, dass die Daten festgeschrieben wurden, wird die
S-Sperre freigegeben. Während der Festschreibung wird eine optimistische Versionsprüfung durchgeführt, um sicherzustellen, dass der
Map-Eintrag nicht von einer anderen Transaktion geändert wurde, nachdem die aktuelle Transaktion die S-Sperre freigegeben hat.
Wenn ein Eintrag nicht aus der Map abgerufen wird, bevor er aktualisiert, ungültig gemacht
oder gelöscht wird, ruft die Laufzeitumgebung von
eXtreme Scale den Eintrag implizit aus der Map ab.
Diese implizite get-Operation wird durchgeführt, um den aktuellen Wert abzurufen, den der Eintrag zum Zeitpunkt
der Änderungsanforderung hatte.
- Anders als bei der pessimistischen Sperrstrategie werden die Methoden "getForUpdate" und "getAllForUpdate"
bei der optimistischen Sperrstrategie genauso wie die Methoden "get" und "getAll" behandelt, d. h.,
beim Starten der Methode wird eine S-Sperre angefordert, die dann freigegeben wird, bevor die Methode zur Anwendung zurückkehrt.
Alle anderen ObjectMap-Methoden werden genauso behandelt, wie es bei der pessimistischen Sperrstrategie der Fall ist,
d. h., wenn die Methode "commit" aufgerufen wird, wird eine X-Sperre für jeden Map-Eintrag angefordert, der
eingefügt, aktualisiert, entfernt, angerührt oder ungültig gemacht wurde, und diese X-Sperre wird so lange gehalten, bis die
Commit-Verarbeitung der Transaktion abgeschlossen ist.
Bei der optimistischen Sperrstrategie wird davon ausgegangen, dass gleichzeitig ausgeführte Transaktionen
nicht versuchen, denselben Map-Eintrag zu aktualisieren.
Aufgrund dieser Annahme müssen die Sperren nicht für die gesamte Lebensdauer der Transaktion gehalten werden,
da es unwahrscheinlich ist, dass mehrere Transaktionen einen Map-Eintrag gleichzeitig aktualisieren.
Da eine Sperre jedoch nicht gehalten wird, ist es potenziell möglich, dass eine andere gleichzeitig ausgeführte Transaktion
den Map-Eintrag ändert, nachdem die aktuelle Transaktion ihre S-Sperre freigegeben hat.
Zur Behandlung dieser Möglichkeit ruft eXtreme Scale während der
Festschreibung eine X-Sperre ab und führt eine optimistische Versionsprüfung durch, um sicherzustellen, dass der
Map-Eintrag nicht von einer anderen Transaktion geändert wurde, nachdem die aktuelle Transaktion den Map-Eintrag aus der BackingMap gelesen hat.
Wenn der Map-Eintrag von einer anderen Transaktion geändert wurde, fällt die Versionsprüfung negativ aus, und es wird eine Ausnahme des
Typs "OptimisticCollisionException" ausgegeben.
Diese Ausnahme erzwingt ein Rollback der aktuellen Transaktion, und die Anwendung muss die vollständige
Transaktion wiederholen.
Die optimistische Sperrstrategie ist sehr hilfreich, wenn eine Map hauptsächlich nur gelesen wird und es unwahrscheinlich ist,
dass gleichzeitige Aktualisierungen an demselben Map-Eintrag vorgenommen werden.
Ohne Sperren
Wenn
eine BackingMap ohne Sperrstrategie konfiguriert ist, werden keine Transaktionssperren für einen Map-Eintrag angefordert.
Dies ist hilfreich, wenn eine Anwendung ein Persistenzmanager ist, wie
z. B. ein EJB-Container, oder wenn eine Anwendung Hibernate für das Abrufen persistenter Daten verwendet.
In diesem Szenario ist die BackingMap ohne Loader konfiguriert, und der Persistenzmanager
verwendet die BackingMap als Datencache. Der Persistenzmanager übernimmt die Steuerung des gemeinsamen Zugriffs
für Transaktionen, die auf dieselben Map-Einträge zugreifen.
Für die Steuerung des gemeinsamen Zugriffs muss WebSphere eXtreme Scale keine Transaktionssperren anfordern.
In dieser Situation wird davon ausgegangen, dass der Persistenzmanager
seine Transaktionssperren nicht freigibt, bevor die ObjectGrid-Map mit festgeschriebenen Änderungen aktualisiert wurde.
Wenn der Persistenzmanager seine Sperren freigibt, muss eine pessimistische oder
optimistische Sperrstrategie verwendet werden. Angenommen, der Persistenzmanager eines
EJB-Containers aktualisiert eine ObjectGrid-Map mit Daten, die in der vom EJB-Container verwalteten
Transaktion festgeschrieben wurden. Wenn die Aktualisierung der ObjectGrid-Map stattfindet, bevor
der Persistenzmanager seine Transaktionssperren freigibt, können Sie die Strategie ohne Sperren verwenden.
Wenn die Aktualisierung der ObjectGrid-Map stattfindet, nachdem der Persistenzmanager seine Transaktionssperren freigibt,
müssen Sie die optimistische oder die pessimistische Sperrstrategie verwenden.
Ein weiteres
Szenario, in dem die Strategie ohne Sperren verwendet werden kann, ist das, wenn die Anwendung eine BackingMap direkt verwendet und ein
Loader für die Map konfiguriert ist.
In diesem Szenario verwendet der Loader die Unterstützung für die Steuerung des gemeinsamen Zugriffs, die von einem
Verwaltungssystem für relationale Datenbanken bereitgestellt wird, indem er entweder
Java Database
Connectivity (JDBC) oder Hibernate für den Zugriff auf die Daten in einer relationalen Datenbank verwendet.
Die Loader-Implementierung kann einen optimistischen oder pessimistischen Ansatz verwenden.
Mit einem Loader, der einen optimistischen Sperr- oder Versionssteuerungsansatz verwendet, kann die höchste Anzahl gemeinsamer Zugriffe und die höchste Leistung erzielt werden.
Weitere Informationen zur Implementierung eines optimistischen Sperransatzes finden Sie im Abschnitt
"OptimisticCallback" in Datenbankloader konfigurieren. Wenn Sie einen Loader verwenden,
der die Unterstützung für pessimistisches Sperren eines zugrunde liegenden Back-Ends verwendet, können Sie den Parameter
"forUpdate" verwenden, der an die Methode "get" der Schnittstelle "Loader" übergeben wird. Setzen Sie diesen Parameter auf "true",
wenn die Methode "getForUpdate der Schnittstelle "ObjectMap von der Anwendung zum Abrufen der Daten verwendet wird.
Der Loader kann diesen Parameter verwenden, um festzustellen, ob eine aktualisierbare Sperre für die Zeile, die gelesen wird, angefordert werden muss.
DB2 fordert beispielsweise eine aktualisierbare Sperre an, wenn
eine SQL-Anweisung SELECT eine Klausel FOR
UPDATE enthält.
Dieser Ansatz bietet dieselben Präventionsmechanismen für Deadlocks, die im Abschnitt
Pessimistisches Sperren beschrieben sind.
Weitere Informationen finden Sie in den
Abschnitten Sperren und Sperrenmanager.