Transaktionen in Java

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
App
DB
Commit TX
Transaktion mit JMS
Commit
Queue
App
Commit TX
Transaktion mit JMS
Rollback
Queue
App
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
XA
App
JTA
Commit TX
DB
Commit TX
TX mit DB, JMS und JTA
Commit TX
App
Queue
Commit TX
Log
DB
JTA
Commit TX
Log
Log
TX mit 2 DBs und JTA
Commit TX
App
DB
Commit TX
Log
DB
JTA
Commit TX
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 „AllesOder-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)
BASE
Ausfallsicherheit
(Partition Tolerance)
BASE?
•  Basically Available
•  Soft state
•  Eventually consistent
•  Best-Effort Strategie
TX mit DB, JMS –
Best Effort (1)
App
Queue
Commit TX
(2)
DB
Commit TX
(1)
Nachricht in DB, nicht mehr in Queue
TX mit DB, JMS –
Best Effort (2)
App
Queue
Rollback TX
(2)
DB
Rollback TX
(1)
Nachricht zurück in Queue, nicht in DB
TX mit DB, JMS –
Best Effort (3)
App
Queue
Rollback TX
(2)
DB
Commit TX
(1)
Nachricht in DB, aber auch wieder in Queue –
Duplicate Message Detection notwendig
TX mit DB, JMS –
Best Effort (4)
App
Queue
Commit TX
(1)
DB
Rollback TX
(2)
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