Transaktionsisolation

Für Transaktionen können Sie in jeder BackingMap-Konfiguration eine von drei Sperrstrategien konfigurieren: PESSIMISTIC, OPTIMISTIC oder NONE. Wenn Sie pessimistisches oder optimistisches Sperren verwenden, verwendet eXtreme Scale gemeinsame (S), aktualisierbare (U) und exklusive (X) Sperren, um die Konsistenz zu verwalten. Dieses Sperrverhalten besonders beachtenswert, wenn pessimistisches Sperren verwendet wird, weil optimistische Sperren nicht gehalten werden. Sie können eine von drei Transaktionsisolationsstufen verwenden, um die Sperrsemantik zu optimieren, die eXtreme Scale für die Verwaltung der Konsistenz in den einzelnen Cache-Maps verwendet: repeatable read (wiederholbares Lesen), read committed (Lesen mit COMMIT) oder read uncommitted (Lesen ohne COMMIT).

Übersicht über die Transaktionsisolation

Die Transaktionsisolation definiert, wie die von einer Operation vorgenommenen Änderungen für andere gleichzeitig ausgeführte Operationen sichtbar werden.

WebSphere eXtreme Scale unterstützt drei Transaktionsisolationsstufen, mit denen Sie die Sperrsemantik, die eXtreme Scale für die Verwaltung in den einzelnen Cache-Maps verwendet (repeatable read, read committed oder read uncommitted) weiter optimieren. Die Transaktionsisolationsstufe wird in der Schnittstelle "Session" mit der Methode setTransactionIsolation festgelegt. Die Transaktionsisolationsstufe kann jederzeit im Verlauf der Sitzung geändert werden, wenn keine Transaktion in Bearbeitung ist.

Das Produkt setzt die verschiedenen Transaktionsisolationssemantiken um, indem es die Art und Weise anpasst, in der gemeinsame Sperren (S-Sperren) angefordert und gehalten werden. Die Transaktionsisolation hat keine Auswirkungen auf Maps, die für die Verwendung der optimistischen Sperrstrategie bzw. der Strategie ohne Sperren konfiguriert sind, wenn aktualisierbare Sperren (U-Sperren) angefordert werden.

Wiederholbares Lesen mit pessimistischem Sperren

Die Transaktionsisolationsstufe "repeatable read" (wiederholbares Lesen) ist die Standardeinstellung. Diese Isolationsstufe verhindert fehlerhafte und nicht wiederholbare Leseoperationen, aber keine Scheinleseoperationen. Eine fehlerhafte Leseoperation ist eine Leseoperation, die für Daten ausgeführt werden, die von einer Transaktion geändert, aber nicht festgeschrieben wurden. Eine nicht wiederholbare Leseoperation kann auftreten, wenn bei einer Leseoperation keine Lesesperren angefordert werden. Eine Scheinleseoperation kann auftreten, wenn zwei identische Leseoperationen durchgeführt werden, aber zwei unterschiedliche Ergebnismengen zurückgegeben werden, weil zwischen den Leseoperationen eine Aktualisierung stattgefunden hat. Das Produkt erreicht eine wiederholbare Leseoperation, indem es alle S-Sperren so lange hält, bis die Transaktion, die Eigner der Sperre ist, abgeschlossen wird. Da keine X-Sperre erteilt wird, bis alle S-Sperren freigegeben sind, sehen alle Transaktionen, die eine S-Sperre halten, bei einer Wiederholung der Leseoperation garantiert denselben Wert.
map = session.getMap("Order");
session.setTransactionIsolation(Session.TRANSACTION_REPEATABLE_READ);
session.begin();

// Es wird eine S-Sperre angefordert und gehalten, und der Wert wird in den
// Transaktionscache kopiert.
Order order = (Order) map.get("100");
// Der Eintrag wird aus dem Transaktionscache entfernt.
map.invalidate("100", false);

// Derselbe Wert wird erneut angefordert. Für den Eintrag ist bereits
// eine Sperre gesetzt, und deshalb wird derselbe Wert abgerufen und in
// den Transaktionscache kopiert.
Order order2 (Order) = map.get("100");

// Alle Sperren werden freigegeben, nachdem die Transaktion mit der
// Cache-Map synchronisiert wurde.
session.commit();
Scheinleseoperationen sind möglich, wenn Sie Abfragen oder Indizes verwenden, weil keine Sperren für Datenbereiche angefordert werden, sondern nur für die Cacheeinträge, die dem Index bzw. den Abfragekriterien entsprechen. Beispiel:
session1.setTransactionIsolation(Session.TRANSACTION_REPEATABLE_READ);
session1.begin();

// Es wird eine Abfrage ausgeführt, die einen Bereich von Werten auswählt.
ObjectQuery query = session1.createObjectQuery
    ("SELECT o FROM Order o WHERE o.itemName='Widget'");

// In diesem Fall stimmt nur ein einziger Auftrag (oder) mit dem
// Abfragefilter überein.
// Der Auftrag hat den Schlüssel "100".
// Die Abfragesteuerkomponente fordert eine S-Sperre für den Auftrag "100" an.
Iterator result = query.getResultIterator();

// Eine zweite Transaktion fügt einen Auftrag ein, der der Abfrage ebenfalls entspricht.
Map orderMap = session2.getMap("Order");
orderMap.insert("101", new Order("101", "Widget"));

// Wenn die Abfrage erneut in der aktuellen Transaktion ausgeführt wird,
// ist der neue Auftrag sichtbar und gibt die Aufträge "100" und "101" zurück.
result = query.getResultIterator();

// Alle Sperren werden freigegeben, nachdem die Transaktion mit der
// Cache-Map synchronisiert wurde.
session.commit();

Lesen mit COMMIT mit pessimistischem Sperren

Die Transaktionsisolationssperre "read committed" (Lesen mit COMMIT) kann mit eXtreme Scale verwendet werden. Sie verhindert fehlerhafte Leseoperationen, aber keine wiederholbaren Leseoperationen oder Scheinleseoperationen, und so verwendet eXtreme Scale weiterhin S-Sperren für das Lesen von Daten aus der Cache-Map, die aber sofort wieder freigegeben werden.
map1 = session1.getMap("Order");
session1.setTransactionIsolation(Session.TRANSACTION_READ_COMMITTED);
session1.begin();

// Es wird eine S-Sperre angefordert, die aber sofort wieder freigegeben wird,
// und der Wert wird in den Transaktionscache kopiert.

Order order = (Order) map1.get("100");

// Der Eintrag wird aus dem Transaktionscache entfernt.
map1.invalidate("100", false);

// Eine zweite Transaktion aktualisiert denselben Auftrag (order).
// Sie fordert eine U-Sperre an, aktualisiert den Wert und wird dann festgeschrieben. 
// ObjectGrid fordert während der Festschreibung erfolgreich eine X-Sperre an, da die
// erste Transaktion die Isolationsstufe "read committed" (Lesen mit COMMIT) verwendet.

Map orderMap2 = session2.getMap("Order");
session2.begin();
order2 = (Order) orderMap2.getForUpdate("100");
order2.quantity=2;
orderMap2.update("100", order2);
session2.commit();

// Derselbe Wert wird erneut angefordert. Dieses Mal soll der Wert
// aktualisiert werden, aber es wird schon der neue Wert angezeigt.
Order order1Copy (Order) = map1.getForUpdate("100");

Lesen ohne COMMIT mit pessimistischem Sperren

Die Transaktionsisolationsstufe "read uncommitted" (Lesen ohne COMMIT) kann mit eXtreme Scale verwendet werden. Diese Stufe lässt fehlerhafte Leseoperationen, nicht wiederholbare Leseoperationen und Scheinleseoperationen zu.