Jürgen Höller & Mike Wiesner | SpringSource Transaktionen in Java 

Wieso Transaktionen? •  Datenintegrität – Alles oder nichts (Atomic) – Konsistenz der Daten (Consistency) – Abgrenzung der Transaktionen (Isolation) – Dauerhafte Speicherung (Durable) •  = ACID 

Transaktionen = ACID? •  Klassische ACID-Transaktionen sind sehr beliebt, da – gute Unterstützung in Frameworks und App Servern – hohe Garantien – wenig Fehlerquellen •  Aber: Der Transaktionsbegriff kann viel allgemeiner gesehen werden... 

ACID in Java •  Viele verschiedene APIs: – JDBC – Hibernate – JPA (Java Persistence API) – JMS (Java Message Service) – JTA (Java Transaction API) •  Jeweils: Transaktionsklammer mit spezifischer Semantik 

Transaktion mit einer DB DB App Commit TX 

App Queue Transaktion mit JMS Commit Commit TX 

App Queue Transaktion mit JMS Rollback Rollback TX 

Und wie wird es gemacht? •  Programmatische Transaktionssteuerung – begin/commit/rollback API – JTA, JDBC, JMS, JPA, Hibernate •  Deklarative Transaktionsdemarkation – EJB CMT (auf Basis von JTA) – Spring Framework (alle oben genannten) 

Was ist JTA genau? •  API zur Transaktionssteuerung •  Kernkonzept: Transaktionskoordinator mit mehreren XA Resource Managers – XA-Protokoll wird zur Kommunikation zwischen Koordinator und Resource Manager verwendet •  Ermöglicht ressourcenübergreifende Transaktionen 

Transaktion mit einer DB und JTA DB App Commit TX JTA Commit TX XA 

TX mit DB, JMS und JTA DB App JTA Commit TX Queue Commit TX Commit TX Log Log Log 

Log TX mit 2 DBs und JTA DB App JTA Commit TX Commit TX Commit TX DB Log Log 

2 Phase Commit (2PC) •  Pattern für verteilte Transaktionen mit ACID-Garantien •  Erste Phase: – Prepare: Können alle Ressourcen einen Commit durchführen? •  Zweite Phase: – Commit: Sofern alle beteiligten Ressourcen das Prepare bestätigt haben... 

XA •  Standardisiertes Koordinationsprotokoll für 2PC •  Spezifiziert durch X/Open Group •  Benötigt dezidierte XA-Treiber für alle beteiligten Ressourcen – Datenbanken – Message Broker – etc 

JTA •  API, welche XA zur Transaktionskoordination benutzt •  Zentrale Rolle in der Java EE •  Standalone-Implementierungen verfügbar (Atomikos, ...) •  Eine der möglichen Transaktionsmanagement-Optionen beim Spring Framework 

2PC erfordert Recovery •  Was passiert, wenn eine Ressource nach der Prepare-Phase nicht mehr erreichbar ist? – Fehler in der 2. Phase verletzen das „Alles- Oder-Nichts“ Prinzip – Muss durch Recovery beseitigt werden... falls möglich. 

Recovery-Protokoll •  Alle beteiligten Ressourcen und der Transaktionskoordinator protokollieren den jeweiligen Status der Transaktion •  Transaktions-Recovery anhand dieses Protokolls grundsätzlich möglich •  Protokollierungsaufwand ist Hauptgrund für Performance-Verlust 

Das CAP-Theorem Konsistenz (Consistency) Verfügbarkeit (Availability) Ausfallsicherheit (Partition Tolerance) BASE 

BASE? •  Basically Available •  Soft state •  Eventually consistent •  Best-Effort Strategie 

TX mit DB, JMS – Best Effort (1) DB App Commit TX (1) Queue Commit TX (2) Nachricht in DB, nicht mehr in Queue 

TX mit DB, JMS – Best Effort (2) DB App Rollback TX (1) Queue Rollback TX (2) Nachricht zurück in Queue, nicht in DB 

TX mit DB, JMS – Best Effort (3) DB App Commit TX (1) Queue Rollback TX (2) Nachricht in DB, aber auch wieder in Queue – Duplicate Message Detection notwendig 

TX mit DB, JMS – Best Effort (4) DB App Rollback TX (2) Queue Commit TX (1) Nachricht verloren durch falsche Reihenfolge – bei vernünftigem Arrangement nicht möglich 

Fazit •  Tradeoff zwischen Verfügbarkeit/ Durchsatz und sofortiger Konsistenz •  XA: generische Konsistenzgarantien zu einem hohen Preis •  Best Effort a la Duplicate Message Detection oft der bessere Tradeoff – unter Berücksichtigung der spezifischen Anwendung 

Vielen Dank! •  Jürgen Höller •  Mike Wiesner •  www.springsource.org