Transactions JTA ou LOCAL dans JPA2+Hibernate 3.6.0 ?

Question

Nous sommes en train de repenser notre pile technologique et voici nos choix (nous ne pouvons pas vivre sans Spring et Hibernate en raison de la complexité de l'application). Nous passons également de J2EE 1.4 à Java EE 5.

Pile technologique

1. Java EE 5
2. JPA 2.0 (je sais que Java EE 5 supporte seulement JPA 1.0 mais nous souhaitons utiliser Hibernate comme fournisseur JPA)
3. Hibernate 3.6.0 (Nous avons déjà beaucoup de fichiers hbm avec des types personnalisés etc. donc nous ne voulons pas les migrer pour le moment vers JPA. Cela signifie que que nous voulons que les deux mappings jpa/hbm fonctionnent ensemble, d'où l'utilisation d'Hibernate comme le fournisseur JPA au lieu d'utiliser le fournisseur par défaut fourni avec App Server)

Le problème est que je veux m'en tenir aux transactions locales mais que les autres membres de l'équipe veulent utiliser JTA. Je travaille avec J2EE depuis 9 ans et j'ai entendu à maintes reprises des personnes suggérer de s'en tenir aux transactions locales si je n'ai pas besoin de commits en deux phases. Ce n'est pas seulement pour des raisons de performance, mais le débogage/le dépannage d'une transaction locale est beaucoup plus facile que celui d'une JTA (même si JTA ne fait qu'un seul commit de phase quand c'est nécessaire).

Ma suggestion est d'utiliser la gestion déclarative des transactions de Spring + les transactions locales (HibernateTransactionManager). au lieu du conteneur JTA

Je veux être sûr que je suis paranoïaque ou que mon point de vue est valable. J'aimerais savoir ce que pense le reste du monde de Java EE. Ou bien, s'il vous plaît, indiquez-moi un article approprié.

Answer 1

Comme Duffy l'a déjà mentionné, JTA n'est pas synonyme de commit à 2 phases, ce qui est fait via le protocole XA.

Dans JBoss AS par exemple, vous pouvez choisir explicitement si vous voulez qu'une source de données donnée soit une xa-datasource ou une tx-datasource. Dans les deux cas, les transactions sont gérées via JTA.

Dans certains cas, vous avez peut-être déjà utilisé JTA sans le savoir. Si vous envoyez un message JMS de manière transactionnelle, ou mettez à jour un cache transactionnel dans la même transaction où vous modifiez quelque chose dans une base de données, le gestionnaire de transactions passe automatiquement en mode XA. La source de données représentant votre base de données peut ne pas être XA, mais dans une transaction XA, une ressource est autorisée à être non-XA. Les mises à jour de cette ressource s'effectuent alors via la fonction last resource commit optimization .

Bien qu'il faille toujours calculer les risques et faire ses propres tests, je tiens à mettre en garde contre les craintes non fondées. XA semble être l'une de ces choses que nous, développeurs, avons été élevés à craindre. Une discussion intéressante a eu lieu récemment sur le forum JBoss à ce sujet : quand utiliser xa-datasource .

Le fait est que XA a pu être une technologie complexe avec des implémentations de qualité inférieure dans le passé, mais près d'une décennie et demie depuis cette FUD, ce n'est peut-être plus le cas. Ce qui était une technologie complexe pour les grandes entreprises en 1995 est une technologie courante en 2011.

Comparez cela à la peur que nous avons connue autrefois pour EJB, qui n'a plus rien à voir avec le sujet, ou à la peur des machines virtuelles (qui n'est évidemment pas un problème pour les programmeurs Java), ou encore, lorsque vous participez vraiment à cette industrie depuis longtemps, à la peur de faire quelque chose d'aussi basique que les appels de fonction ;)

Answer 2

JTA ne veut pas dire commits en deux phases. Je pense que c'est la combinaison de JTA et des pilotes XA qui rend les engagements biphasés possibles.

Je recommande toujours d'utiliser JTA et les transactions déclaratives plutôt que d'intégrer la logique de transaction dans le code. Les transactions sont mieux réalisées dans un mode orienté aspect, à la Spring.

UPDATE :

Avec les informations supplémentaires que vous avez postées, je suis d'accord avec votre argument. Je recommanderais d'utiliser les transactions déclaratives de Spring et l'option HibernateTransactionManager classe.