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).
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.
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();
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();
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");
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.