Transaktionen in Java

Transcript

1. Jürgen Höller & Mike Wiesner | SpringSource Transaktionen in Java
2. Wieso Transaktionen? •  Datenintegrität – Alles oder nichts (Atomic) – Konsistenz der Daten (Consistency) – Abgrenzung der Transaktionen (Isolation) – Dauerhafte Speicherung (Durable) •  = ACID
3. 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...
4. 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
5. Transaktion mit einer DB DB App Commit TX
6. App Queue Transaktion mit JMS Commit Commit TX
7. App Queue Transaktion mit JMS Rollback Rollback TX
8. 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)
9. 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
10. Transaktion mit einer DB und JTA DB App Commit TX JTA Commit TX XA
11. TX mit DB, JMS und JTA DB App JTA Commit TX Queue Commit TX Commit TX Log Log Log
12. Log TX mit 2 DBs und JTA DB App JTA Commit TX Commit TX Commit TX DB Log Log
13. 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...
14. 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
15. 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
16. 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.
17. 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
18. Das CAP-Theorem Konsistenz (Consistency) Verfügbarkeit (Availability) Ausfallsicherheit (Partition Tolerance) BASE
19. BASE? •  Basically Available •  Soft state •  Eventually consistent •  Best-Effort Strategie
20. TX mit DB, JMS – Best Effort (1) DB App Commit TX (1) Queue Commit TX (2) Nachricht in DB, nicht mehr in Queue
21. TX mit DB, JMS – Best Effort (2) DB App Rollback TX (1) Queue Rollback TX (2) Nachricht zurück in Queue, nicht in DB
22. 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
23. 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
24. 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
25. Vielen Dank! •  Jürgen Höller •  Mike Wiesner •  www.springsource.org