Subscribe
JTA

Atomikos - Le gestionnaire de transaction JTA qu'il vous faut!

Atomikos - Le gestionnaire de transaction JTA qu'il vous faut!

En Java, il est possible de développer des applications faisant appel à des standards J2EE … ou non, d’utiliser l’ensemble des ressources mise à disposition par des serveurs d’applications J2EE… ou non, d’exploiter les technologies EJB … ou non. Cependant, Sun a toujours poussé à utiliser les serveurs d’applications J2EE pour déployer les applications d’entreprises pour en exploiter toutes les technologies proposées par SUN.

Bref, on a le choix de développer des applications qui exploitent les technos J2EE un peu comme on l’entend, mais si on les déploie pas dans un serveur d’applications, on ne pourra pas tirer partie de toutes les ressources offertes par ces derniers. Cela pour procurer un certain nombre d’avantages (Test hors conteneur possibles et simples à mettre en oeuvre), mais on aura plus de mal à assembler toutes les pièces du puzzle.

Par exemple, si vous ne voulez pas développer d’EJB, vous pouvez toujours utiliser des services Pojo Spring. De même si vous ne voulez pas gérer la persistence avec les EJB, vous pouvez toujours en la gérer avec Hibernate ou bien JPA.

De même qu’on peut exploiter des ressources J2EE lorsqu’on déploie une application dans un serveur J2EE, on peut le faire également hors conteneur, mais ceci devient très vite compliqué. Ces possibilités qui n’étaient pas envisageables il y a encore peu de temps, sont encore difficiles à mettre en oeuvre à cause du manque d’exemples et de documentations.

Même s’il est simple d’utiliser des technos telles que des Pools de Threads et de Connections, des MQ ou des DataSources, de gérer des transactions, il est en revanche plus difficile par exemple de gérer des applications clusterisées ou bien de mettre en oeuvres des transactions gérant plusieurs ressources sans serveurs d’applications. Les gestionnaires de transactions JTA permettre de répondre besoin de gérer des transactions gérant plusieurs ressources. Cependant, on les trouve en général uniquement dans des serveurs d’applications, donc même si on construit une applications autour de technos non dépendantes des serveurs d’applications, il faut quand même les déployer dans des serveurs d’applications J2EE, si on veut on veut profiter de transactions 2PC (Two Phase Commit). Nous voila revenu au point de départ: Comment se passer complètement d’un serveur d’applications pour gérer des transactions 2PC?

Les gestionnaires de transactions JTA fournissant une implémentation indépendante sont les suivants:

  • Bitronix
  • Atomikos
  • JOTM
  • JBoss Transactions
  • Jencks (Via les librairies de Géronimo)
  • Le Gestionnaire de transaction de Géronimo

Cependant, après vérification :

  • JOTM semblerait à l’abandon, et
  • Jencks, bien qu’intéressant, semble difficile à mettre en oeuvre (De ma propre expérience, peu de matériel et d’explications sont fournies au final pour supporter différentes ressources), ActiveMQ est cependant bien supporté. Personnellement, je n’ai as réussi à mettre en oeuvre des transactions 2PC avec Oracle et ActiveMQ.
  • JBoss Transaction et le Gestionnaire de transaction de Geronimo

Pour ma part, je n’ai pas testé Bitronix, et je ne peux donc pas donner d’avis, mais il semblerait qu’Atomikos soit une très bonne solution pour les raisons suivantes:

  • Il supporte un grand nombre de ressources XA (JMS, JDBC, JCA, JMX)
  • JMS: ActiveMQ, OracleAQ, SonicMQ, …
  • JDBC: Tout driver et Bases de donnée XA “compliant”: Oracle par exemple, ainsi qu’un certain nombre de driver ou Base de données pas complètement “Compliant” (MySQL par exemple).
  • Le projet est mature (6 ans d’existance)
  • Le projet est Open-Source, mais propose un support professionnel
  • Il existe un support communautaire plus développé via un forum de support mis en place par la société qui le développe.
  • Une document très fournie sur JTA et les API Atomikos
  • Atomikos peut être mis en oeuvre facilement via Spring.
  • Atomikos propose des consommateurs de messages bien plus intéressants que ceux proposés par défaut dans spring. En effet, la classe ‘DefaultMesssageListenerContainer’ poll les ressources JMS (Génération très lourde de traffic – Connections, session, consumer transaction – pour simuler la réception de message. C’est un peu comme si on disait que du pop par intermittence de 10 secondes était du Push Mail pour imager), alors que la classe QueueServerSessionPool attend que le serveur push les messages JMS, ce qui est le pattern de fonctionnement par défaut de JMS pour écouter l’arrivée de messages asynchrones)

Grâce à Atomikos et Spring, il devient possible de déployer simplement une application J2EE hors conteneur tout en gérant des ressources XA telles qu’une base Oracle via un gestionnaire ORM par exemple ou bien un broker JMS tout en gérant ces ressources via des transactions 2PC.

On pourrait facilement imaginer une application Web déployer dans un conteneur Web (Tomcat par exemple) qui contiendrait les technos suivantes:

  • Spring 2 pour l’injection de Dépendence et la glue techniques de l’application
  • Atomikos pour gérer les transaction 2PC (JTA/XA)
  • JPA utilisant des ressource JDBC XA “Compliant” (Oracle, SQLServer, Informix, FirstSQL Enterprise) ou non mais supportés (MySQL / HyperSonic)
  • Un Broker JMS XA “Compliant” (SonicMQ, MQSeries, ActiveMQ, Oracle AQ)
  • Un FrameWork Web quelconque: Struts 1.x/2.x, …
  • D’autres Technos fournies par Spring par exemple: WebService via XFire…

Voici de quoi se mettre un peu de lecture sous la dent: