JTA oder lokale Transaktionen in JPA2 + Hibernate 3.6.0?

Question

Wir sind dabei, unseren Tech-Stack neu zu denken und unten sind unsere Entscheidungen (Wir können nicht ohne Spring und Hibernate aufgrund der Komplexität usw. der App leben). Wir sind auch von J2EE 1.4 zu Java EE bewegen 5.

Technologie-Stack

1. Java EE 5
2. JPA 2.0 (Ich weiß, Java EE 5 unterstützt nur JPA 1.0, aber wir wollen Hibernate verwenden als JPA-Provider)
3. Hibernate 3.6.0 (wir haben bereits viele hbm Dateien mit benutzerdefinierten Typen etc., so will man nicht sie zu diesem Zeitpunkt JPA migrieren. das bedeutet, wollen wir beide JPA/hbm Zuordnungen arbeiten zusammen und damit die Hibernate als der JPA-Provider statt die Standardeinstellung verwenden, die

Nun sind die Probleme mit App Server) kommt, ist, dass ich mit den lokalen Geschäften, sondern auch andere Teammitglieder bleiben wollen wollen benutze JTA. Ich arbeite seit 9 Jahren mit J2EE und ich habe immer wieder Leute gehört, die vorschlagen, bei lokalen Transaktionen zu bleiben, wenn ich keine zweiphasigen Commits brauche. Dies ist nicht nur aus Performance-Gründen, sondern Debugging/Troubleshooting einer lokalen Transaktion ist viel einfacher als ein JTA (auch wenn JTA nur einphasige Festschreibung bei Bedarf).

Mein Vorschlag ist Frühling deklarative Transaktionsmanagement + lokale Transaktionen (HibernateTransactionManager) statt Behälter JTA

ich sicherstellen möchten, verwenden, wenn ich paranoid bin zu sein oder ich habe einen wichtigen Punkt. Ich würde gerne hören, was der Rest der Java EE Welt denkt. Oder bitte zeigen Sie mir einen entsprechenden Artikel.

Answer 1

JTA bedeutet nicht zweiphasige Commits. Ich denke, es ist die Kombination von JTA- und XA-Treibern, die Zwei-Phasen-Commits ermöglicht.

Ich würde immer noch empfehlen, JTA und deklarative Transaktionen über das Einbetten von Transaktionslogik in Code zu verwenden. Transaktionen werden am besten in einer aspektorientierten Mode durchgeführt, a la Spring.

UPDATE:

Mit der zusätzlichen Informationen, die Sie geschrieben haben, ich bin einverstanden mit dem Argument. Ich würde empfehlen, Spring deklarative Transaktionen und die HibernateTransactionManager Klasse zu verwenden.

Answer 2

Wie Duffy bereits erwähnt, ist JTA auch nicht mit 2-Phasen-Commit, was etwas über das XA-Protokoll getan wird.

In JBoss AS können Sie beispielsweise explizit auswählen, ob eine bestimmte Datenquelle eine xa-Datenquelle oder eine tx-Datenquelle sein soll. In beiden Fällen werden Transaktionen über JTA verwaltet.

In einigen Fällen haben Sie JTA bereits verwendet, ohne es zu wissen. Wenn Sie eine JMS-Nachricht transaktional senden oder einen Transaktionscache in derselben Transaktion aktualisieren, in der Sie etwas in einer Datenbank ändern, wechselt der Transaktionsmanager automatisch in den XA-Modus. Die Datenquelle, die Ihre DB darstellt, ist möglicherweise nicht XA, aber in einer XA-Transaktion darf die Ressource 1 nicht-XA sein. Aktualisierungen dieser Ressource erfolgen dann über die last resource commit optimization.

Obwohl Sie immer die Risiken berechnen und für sich selbst testen sollten, möchte ich vor unbegründeter Angst warnen. XA scheint eines dieser Dinge zu sein, die wir als Entwickler fürchten mussten. Es gab kürzlich eine interessante Diskussion über das JBoss-Forum: when to use xa-datasource.

Die Sache ist, dass XA in der Vergangenheit eine komplexe Technologie mit untergeordneten Implementierungen gewesen sein könnte, aber fast anderthalb Jahrzehnte nach dieser FUD ist dies vielleicht nicht mehr der Fall. Was war komplexe Großunternehmen Zeug im Jahr 1995 ist Ihre gemeinsame Lauf der Mühle Technologie im Jahr 2011.

Vergleichen Sie dies mit der Angst, die wir einmal für EJB aufgewachsen sind, die jetzt völlig irrelevant ist, oder die Angst vor virtuellen Maschinen (offensichtlich kein Problem für Java-Programmierer), oder wenn Sie wirklich in dieser Branche für eine lange Zeit teilnehmen, die Angst, etwas so grundlegendes wie Funktionsaufrufe zu tun;)