Discussion :

[jlinho2]

Bonjour,

je souhaiterais comprendre dans le détail JTA: les liens entre transaction, connexion, thread etc.... Comment un contexte transactionnel peut être propagé entre un client lourd et un serveur d'application par exemple. etc.

J'ai en particulier les questions suivantes:

1) Je m'imagine un service JTA comme un serveur/service indépendant qui peut recevoir des requêtes depuis un client local ou distant: Ces requêtes sont alors du genre "démarre moi une transaction sur cette connection", "commit la", "rollback la" etc... Je le vois donc vraiment comme un serveur/service à part: qui garde des connexions à une (ou plus) BDD et qui délimite des transactions dessus sur ordre d'un client. Cette représentation mentale est-elle correcte ?

Dans cette modélisation, le client distant d'un service JTA ne possède pas de socket ouverte vers la BDD mais c'est le serveur qui ouvre une connexion pour le client. Juste ?

Client ------(RMI-IIOP)----->Service JTA /Driver JDBC ----(TCP)----->BDD

2) Au final, vu de la base de donnée, un commit/rollback se fait toujours sur une connexion TCP donnée, non ? Au final le service JTA ferait donc bien un connexion.commit() (ou plutôt XAResource.end() ), il travaillerai donc en arriére plan sur un object connexion (ou semblable). Suis-je complètement à côté de la plaque ?

3) Lorsque dans un serveur J2EE, on veut effectuer une transaction "à la main", il faut récupérer un object "UserTransaction" et de maniére conplètement indépendante un object "DataSource"(et donc une connexion).
Si le service JTA committe au final sur un object semblable à une connexion, comment le service JTA fait-il le lien entre les opérations faites sur la connexion obtenue par la datasource et les begin() end commit() appelés sur l'object UserTransaction. Le lien entre la Transaction courante et la connexion est-il fait implicitement car les 2 sont utilisés dans le même Thread? (genre le service JTA, au start() associe la transacion au thread courant et dès l'utilisation de la connexion celle-ci est également associée au thread courant, donc au final la connexion est enregistrée sur la transaction ouverte ?)



3) Prenons le cas d'une transaction initiée par le client sur un poste A, et ce client fait appel à 2 EJBs(par exemple avec attribut transactionnel REQUIRED) dans la même transaction. La encore le client récupère par un appel JNDI un UserTransaction et par un appel JNDI conplétement différent une DataSource et donc une connexion. Comment le service JTA sait-il qu'il faut effectuer des commit/rollback sur cette connexion particulière ?


Merci d'avance pour votre aide.

[Gob4]

Bonjour jlinho2,

Il se trouve que j'ai les mêmes incompréhensions que toi dans ce domaine (je suis d'ailleurs tombé sur ton poste et cherchant des réponses à ces questions).

Je ne peux donc malheureusement pas répondre à tes questions mais je serais très intéressé par des éléments de réponse... As-tu trouvé des articles où des tutoriels intéressants sur ce sujet ? Quelqu'un peut-il nous aider sur ce point ?

Merci.

[jlinho2]

Bonjour Gob4,

oui j'ai appris beaucoup de choses depuis. Puisque tu es intéressé je posterai une entrée ici dans les jours à venir (dès que j'aurais un peu de temps par exemple ce week-end).

Le meilleur livre - et de loin - que je peux te conseiller est: "Java Transaction Processing" de Mark Little. Malheureusement, on n'en trouve pas d'e-book sur le web car visiblement le sujet intéresse pas tant de monde.. :-( En lisant les 4 premiers chapitres tu comprendras:

• Chapitre 1: Le rôle d'un moniteur transactionnel (cad un service de transaction à la JTA): enlistement des participants, coordination des participants dans la phase de commit, recovery, propagation des contextes
• Chapitre 2: Le détail de JTA ainsi que comment celà est implémenté le plus souvent, les associations Thread/contexte de transaction etc. .
• Chapitre 3: JTS, Corba OTS ainsi que comment celà peut/est implmenté et ce qui fait la différence entre un bon et un mauvais service de transaction ( a noter que ce chapitre est un peu dûr à lire)
• Chapitre 4: Les transactions JTA (ou locales) avec JDBC, le travail que fait le serveur d'application dans ce cas là, mais que tu ne vois pas: Par exemple, le serveur d'aplication passe un proxy de Connection au client, ce qui lui permet de détecter les évènements essentiels pour savoir quand enregistrer la connexion au prés du service de transaction, quand retourner la connexion dans le pool etc...
• Chapitre 5: Les transactions et JMS, on comprend tout ce que doit faire le serveur d'application derrière la scène, mais en lisant les chapitres précédent on a tout de suite déjà deviner comment ça fonctionne car c'est similaire
• Chapitre 6: Un survol des transactions EJB, pas utile à lire si tu connais déjà les EJB. Concernant l'implémentation d'un serveur d'application tout est déjà expliqué dans les chapitres précédent et ce n'est donc pas le rôle de ce chapitre
• Les chapitres suivants sont probablement intéressants mais je ne les ai pas lus ...

Bon je conçois que tout se que je dis n'est pas forcément clair mais ce livre répondra à toutes tes interrogations..

Sinon le meilleur livre pour comprendre l'intérêt des différentes stratégies d'implémentation des transactions et implémenter correctement est le livre gratuit: "Java Transaction Design Stratégies" de Mark Richards. Il est lisible très facilement et l'essentiel est couvert en une quarantaine de pages. Le livre est téléchargeable sur InfoQ par exemple.

A bientôt, pour une description détaillée donc ...