Beispiel: Konsistenzprüfung beim erneuten Lesen
Die Konsistenzprüfung bei erneutem Lesen wird nur auf LifeTimeInCache-Beans angewendet, deren Daten von einer anderen Transaktion gelesen werden.
Einsatzszenario
Bei Zugriffsarten für die Isolationsstufe wiederholbares Lesen überprüft das Produkt, ob die Daten mit denen im Datenspeicher konsistent sind, und stellt sicher, dass die Daten nach der Überprüfung nicht aktualisiert werden. Bei Zugriffsarten für die Isolationsstufe festgeschriebene Daten lesen überprüft das Produkt, ob die Daten zum Zeitpunkt der Prüfung konsistent sind, stellt jedoch nicht sicher, dass die Daten nach der Überprüfung nicht aktualisiert werden. Die LifeTimeInCache-Bean verhält sich dann genauso wie Nicht-LifeTimeInCache-Beans.
Die folgenden drei Szenarien zur Berechnung der Zinsen für Annas Konto zeigen die drei möglichen Optionen für das Definieren der Konsistenzprüfung. Der Datenspeicher wird in allen Fällen von dieser EJB-CMP-Anwendung (zur Berechnung der Zinsen) und anderen Anwendungen (z. B. EJB-BMP- und JDBC-Anwendungen oder herkömmlichen Anwendungen) gemeinsam benutzt. Die EJB account ist in allen Fällen als langlebige Bean konfiguriert.
OHNE
- Der Server wird gestartet.
- Benutzer 1 ruft in Transaktion 1 Account.findByPrimaryKey("10001") auf. Die Kontodaten für Anna werden aus der Datenbank gelesen und zeigen einen Kontostand von $ 100.
- Annas Eintrag wird vom Persistenzmanager (PM) auf dem Server zwischengespeichert.
- Benutzer 2 schreibt einen JDBC-Aufruf und ändert den Kontostand in $ 120.
- Benutzer 3 ruft in Transaktion 2 Account.findByPrimaryKey() für das Konto "10001" auf. Annas Daten werden mit dem Kontostand $ 100 aus dem Cache gelesen.
- Annas Zinsen werden berechnet. Das Ergebnis könnte aufgrund der verletzten Datenintegrität jedoch falsch sein.
Überprüfung bei erneutem Lesen - AT_TRAN_BEGIN
- Der Server wird gestartet.
- Benutzer 1 ruft in Transaktion 1 Account.findByPrimaryKey("10001") auf. Die Kontodaten für Anna werden aus der Datenbank gelesen und zeigen einen Kontostand von $ 100.
- Annas Eintrag wird vom Persistenzmanager (PM) auf dem Server zwischengespeichert.
- Benutzer 2 schreibt einen JDBC-Aufruf und ändert den Kontostand in $ 120.
- Benutzer 3 ruft in Transaktion 2 Account.findByPrimaryKey() für das Konto "10001" auf. Annas Daten werden mit dem Kontostand $ 100 aus dem Cache gelesen.
- Der PM liest Annas Kontodaten zur Prüfung erneut und stellt fest, dass sich der Kontostand geändert hat. Er setzt eine Datenbankabfrage ab, um den Kontostand von $ 120 abzurufen. Annas Daten im Cache werden aktualisiert.
- Annas Zinsen werden berechnet. Die Transaktion kann fortgesetzt werden, da die Datenintegrität gewährleistet ist.
Überprüfung bei erneutem Lesen - AT_TRAN_END
- Der Server wird gestartet.
- Benutzer 1 ruft in Transaktion 1 Account.findByPrimaryKey("10001") auf. Die Kontodaten für Anna werden aus der Datenbank gelesen und zeigen einen Kontostand von $ 100.
- Annas Eintrag wird vom Persistenzmanager (PM) auf dem Server zwischengespeichert.
- Benutzer 2 schreibt einen JDBC-Aufruf und ändert den Kontostand in $ 120.
- Benutzer 3 ruft in Transaktion 2 Account.findByPrimaryKey() für das Konto "10001" auf. Annas Daten werden mit dem Kontostand $ 100 aus der Datenbank gelesen.
- Die Zinsen für Anna werden berechnet.
- Am Ende der Transaktion liest der PM Annas Kontodaten zur Prüfung erneut und stellt fest, dass sich der Kontostand geändert hat.
- Der PM setzt die Transaktion zurück und annulliert den Cacheinhalt. Die Transaktion scheitert, so dass die Datenintegrität auch hier gewährleistet ist.