j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il
faudrait que certains appellent métier se comportent comme s'ils étaient
imbriqués dans la même transaction, c'est-à-dire que si un appel échoue
alors je devrai faire un rollback de toute les transactions (même celles
réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de
mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet?
Je suis également preneur de tout conseil ou suggestion!
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Symon
Je ne suis pas sur que ca réponde à votre problème, mais voila ce qu'on a mis en place chez nous, mais ça ne marche qu'avec Oracle et un JRE 1.4 ou plus :
Si vous utilisez Oracle et un JRE 1.4 minimum donc, vous pouvez utiliser un savepoint... Derrière, vous pouvez committer normalement vos transactions. Des qu'une exception survient, il suffit de faire un "rollback to savepoint".
Symon
Seb wrote:
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
Merci Seb
Je ne suis pas sur que ca réponde à votre problème, mais voila ce qu'on
a mis en place chez nous, mais ça ne marche qu'avec Oracle et un JRE 1.4
ou plus :
Si vous utilisez Oracle et un JRE 1.4 minimum donc, vous pouvez utiliser
un savepoint... Derrière, vous pouvez committer normalement vos
transactions. Des qu'une exception survient, il suffit de faire un
"rollback to savepoint".
Symon
Seb wrote:
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il
faudrait que certains appellent métier se comportent comme s'ils étaient
imbriqués dans la même transaction, c'est-à-dire que si un appel échoue
alors je devrai faire un rollback de toute les transactions (même celles
réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de
mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet?
Je suis également preneur de tout conseil ou suggestion!
Je ne suis pas sur que ca réponde à votre problème, mais voila ce qu'on a mis en place chez nous, mais ça ne marche qu'avec Oracle et un JRE 1.4 ou plus :
Si vous utilisez Oracle et un JRE 1.4 minimum donc, vous pouvez utiliser un savepoint... Derrière, vous pouvez committer normalement vos transactions. Des qu'une exception survient, il suffit de faire un "rollback to savepoint".
Symon
Seb wrote:
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
Merci Seb
Trognon Patrice
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
Votre adresse mail c'est quoi je vous send mes tutoriaux en pv.
je traite tous les cas, DAO montant tout le query en cache. DAO fetchant a chaque iteration. DAO fetchant par buffer.
Le troisiéme etant la meilleur solution en utilisation par RMI.
Patrice Trognon. http:/www.javadevel.com
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il
faudrait que certains appellent métier se comportent comme s'ils étaient
imbriqués dans la même transaction, c'est-à-dire que si un appel échoue
alors je devrai faire un rollback de toute les transactions (même celles
réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de
mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le
sujet? Je suis également preneur de tout conseil ou suggestion!
Votre adresse mail c'est quoi je vous send mes tutoriaux en pv.
je traite tous les cas,
DAO montant tout le query en cache.
DAO fetchant a chaque iteration.
DAO fetchant par buffer.
Le troisiéme etant la meilleur solution en utilisation par RMI.
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
Votre adresse mail c'est quoi je vous send mes tutoriaux en pv.
je traite tous les cas, DAO montant tout le query en cache. DAO fetchant a chaque iteration. DAO fetchant par buffer.
Le troisiéme etant la meilleur solution en utilisation par RMI.
Patrice Trognon. http:/www.javadevel.com
Trognon Patrice
Trognon Patrice wrote:
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
Votre adresse mail c'est quoi je vous send mes tutoriaux en pv.
je traite tous les cas, DAO montant tout le query en cache. DAO fetchant a chaque iteration. DAO fetchant par buffer.
Le troisiéme etant la meilleur solution en utilisation par RMI.
oups désolé, je me suis trompé de thread pour poster.
Trognon Patrice wrote:
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il
faudrait que certains appellent métier se comportent comme s'ils étaient
imbriqués dans la même transaction, c'est-à-dire que si un appel échoue
alors je devrai faire un rollback de toute les transactions (même celles
réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit
de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le
sujet? Je suis également preneur de tout conseil ou suggestion!
Votre adresse mail c'est quoi je vous send mes tutoriaux en pv.
je traite tous les cas,
DAO montant tout le query en cache.
DAO fetchant a chaque iteration.
DAO fetchant par buffer.
Le troisiéme etant la meilleur solution en utilisation par RMI.
oups désolé, je me suis trompé de thread pour poster.
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
Votre adresse mail c'est quoi je vous send mes tutoriaux en pv.
je traite tous les cas, DAO montant tout le query en cache. DAO fetchant a chaque iteration. DAO fetchant par buffer.
Le troisiéme etant la meilleur solution en utilisation par RMI.
oups désolé, je me suis trompé de thread pour poster.
kanari666
bonjour,
ca me fait penser à l'orchestration des web-services : tu crees un transaction-monitor qui lance les 2 opérations : chacune fait sa vie de son coté et notifie le monitor si elle a réussi ou pas. En cas d'échec d'un des enfants, tu annules le tout (ou tu demandes à chaque enfant d'annuler ce qu'il fait et a fait). En espérant t'avoir aidé....
bonjour,
ca me fait penser à l'orchestration des web-services :
tu crees un transaction-monitor qui lance les 2 opérations : chacune
fait sa vie de son coté et notifie le monitor si elle a réussi ou
pas.
En cas d'échec d'un des enfants, tu annules le tout (ou tu demandes à
chaque enfant d'annuler ce qu'il fait et a fait).
En espérant t'avoir aidé....
ca me fait penser à l'orchestration des web-services : tu crees un transaction-monitor qui lance les 2 opérations : chacune fait sa vie de son coté et notifie le monitor si elle a réussi ou pas. En cas d'échec d'un des enfants, tu annules le tout (ou tu demandes à chaque enfant d'annuler ce qu'il fait et a fait). En espérant t'avoir aidé....
Patrick Gras
"Seb" wrote in message news:41e5adb2$0$7122$
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet?
Je suis également preneur de tout conseil ou suggestion!
Merci Seb
Bonjour,
Sans entrer dans les détails tu cherches à faire une transaction qui englobe plusieurs ressources...
Donc il faut utiliser JTA -- ce qui implique un container J2EE -- ainsi que l'utilisation de ressources container XA-capable publiées via JNDI.
Je ne sais pas si tous cela est possible dans ton cas (je ne sais pas ce que tu appelle dans tes serveurs WAS) mais si c'est des EJB il faut en plus qu'ils ne soient pas CMT (ContainerManagedTransaction)...
En plus je ne sais pas si JTA est disponible pour Tomcat...
Une piste à explorer est d'ajouter une façade dans un des serveur WAS qui fera l'appel à tes différents services (dans les deux was...)
-Patrick
"Seb" <coach2_NO@SPAM_free.fr> wrote in message
news:41e5adb2$0$7122$8fcfb975@news.wanadoo.fr...
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il
faudrait que certains appellent métier se comportent comme s'ils étaient
imbriqués dans la même transaction, c'est-à-dire que si un appel échoue
alors je devrai faire un rollback de toute les transactions (même celles
réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de
mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le
sujet?
Je suis également preneur de tout conseil ou suggestion!
Merci
Seb
Bonjour,
Sans entrer dans les détails tu cherches à faire une transaction qui englobe
plusieurs ressources...
Donc il faut utiliser JTA -- ce qui implique un container J2EE -- ainsi que
l'utilisation de ressources container XA-capable publiées via JNDI.
Je ne sais pas si tous cela est possible dans ton cas (je ne sais pas ce que
tu appelle dans tes serveurs WAS) mais si c'est des EJB il faut en plus
qu'ils ne soient pas CMT (ContainerManagedTransaction)...
En plus je ne sais pas si JTA est disponible pour Tomcat...
Une piste à explorer est d'ajouter une façade dans un des serveur WAS qui
fera l'appel à tes différents services (dans les deux was...)
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet?
Je suis également preneur de tout conseil ou suggestion!
Merci Seb
Bonjour,
Sans entrer dans les détails tu cherches à faire une transaction qui englobe plusieurs ressources...
Donc il faut utiliser JTA -- ce qui implique un container J2EE -- ainsi que l'utilisation de ressources container XA-capable publiées via JNDI.
Je ne sais pas si tous cela est possible dans ton cas (je ne sais pas ce que tu appelle dans tes serveurs WAS) mais si c'est des EJB il faut en plus qu'ils ne soient pas CMT (ContainerManagedTransaction)...
En plus je ne sais pas si JTA est disponible pour Tomcat...
Une piste à explorer est d'ajouter une façade dans un des serveur WAS qui fera l'appel à tes différents services (dans les deux was...)
-Patrick
Frédéric Lachasse
"Seb" wrote in message news:41e5adb2$0$7122$
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
La théorie J2EE veut que cela peut se faire simplement en utilisant l'objet javax.transaction.UserTransaction, appeler begin(), faire les appels aux différentes méthodes des EJB, puis appeler commit() ou rollback().
Dans la pratique, cela ne marche pas. Cela est effectivement très complexe à implémenter dans le meilleur des cas, et les performances sont très mauvaises, donc par défaut, ce type de fonctionnement est rarement activé et configuré, à condition que cela soit supporté par le containeur J2EE...
En effet, il faut pour que cela marche: 1) Un moniteur transactionnel avec une interface JTA 2) Que les différents composants EJB participant à la transaction soit configuré pour utiliser ce moniteur transctionnel. 3) Que les bases de données participants à la transactions soit configurées pour utiliser le commit à 2 phases avec ce moniteur transactionnel. 4) Que tu aies accès à l'object javax.transaction.UserTransaction
Note: je peux déjà dire que WAS ne supporte pas (4) dans Tomcat...
En fait, je conseille fortement de rechercher d'autres alternatives. Elles sont plus compliquées à programmer, mais plus facile à configurer et offrent de bien meilleures performances. Une option est d'utiliser des queues de messages persistants avec JMS.
Un cas classique: transfert d'argent. Un compte est débité sur une machine, l'argent est envoyé avec un message persistant vers l'autre machine qui va le créditer sur le compte destinataire.
L'intérêt de JMS (implémenté par WebSphere MQ dans WAS) est que: - le message n'est créé que si la transaction "débit" est réussie - le système guarantie que le message sera transmis (c'est aussi fiable qu'une base de donnée) - le message ne sera retiré de la queue que si la transaction "crédit" réussie.
L'aspect complexe est qu'il faut gérer les messages dont la transction "crédit" échoue (comme le renvoyer à l'originateur). Il faut accepter aussi la limitation que l'argent n'est pas disponible pendant le transfert du message. Cela n'est pas aussi problèmatique que cela semble. En effet, utiliser un commit à deux phases au lieux d'un message peut provoquer un problème plus grand, car si un problème arrive pendant le commit, les deux comptes sont bloqués tant que la transaction n'est pas résolue (complètement committée ou complètement rollbackée). Ai-je dis que les transactions globales ont des problèmes de performance?
-- Frédéric Lachasse - ECP86
"Seb" <coach2_NO@SPAM_free.fr> wrote in message
news:41e5adb2$0$7122$8fcfb975@news.wanadoo.fr...
Bonsoir,
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il
faudrait que certains appellent métier se comportent comme s'ils étaient
imbriqués dans la même transaction, c'est-à-dire que si un appel échoue
alors je devrai faire un rollback de toute les transactions (même celles
réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de
mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le
sujet? Je suis également preneur de tout conseil ou suggestion!
La théorie J2EE veut que cela peut se faire simplement en utilisant l'objet
javax.transaction.UserTransaction, appeler begin(), faire les appels aux
différentes méthodes des EJB, puis appeler commit() ou rollback().
Dans la pratique, cela ne marche pas. Cela est effectivement très complexe à
implémenter dans le meilleur des cas, et les performances sont très
mauvaises, donc par défaut, ce type de fonctionnement est rarement activé et
configuré, à condition que cela soit supporté par le containeur J2EE...
En effet, il faut pour que cela marche:
1) Un moniteur transactionnel avec une interface JTA
2) Que les différents composants EJB participant à la transaction soit
configuré pour utiliser ce moniteur transctionnel.
3) Que les bases de données participants à la transactions soit
configurées pour utiliser le commit à 2 phases avec ce moniteur
transactionnel.
4) Que tu aies accès à l'object javax.transaction.UserTransaction
Note: je peux déjà dire que WAS ne supporte pas (4) dans Tomcat...
En fait, je conseille fortement de rechercher d'autres alternatives. Elles
sont plus compliquées à programmer, mais plus facile à configurer et offrent
de bien meilleures performances. Une option est d'utiliser des queues de
messages persistants avec JMS.
Un cas classique: transfert d'argent. Un compte est débité sur une machine,
l'argent est envoyé avec un message persistant vers l'autre machine qui va
le créditer sur le compte destinataire.
L'intérêt de JMS (implémenté par WebSphere MQ dans WAS) est que:
- le message n'est créé que si la transaction "débit" est réussie
- le système guarantie que le message sera transmis (c'est aussi fiable
qu'une base de donnée)
- le message ne sera retiré de la queue que si la transaction "crédit"
réussie.
L'aspect complexe est qu'il faut gérer les messages dont la transction
"crédit" échoue (comme le renvoyer à l'originateur). Il faut accepter aussi
la limitation que l'argent n'est pas disponible pendant le transfert du
message. Cela n'est pas aussi problèmatique que cela semble. En effet,
utiliser un commit à deux phases au lieux d'un message peut provoquer un
problème plus grand, car si un problème arrive pendant le commit, les deux
comptes sont bloqués tant que la transaction n'est pas résolue (complètement
committée ou complètement rollbackée). Ai-je dis que les transactions
globales ont des problèmes de performance?
j'ai une appli Web sous tomcat qui interagit avec 2 serveurs WAS; il faudrait que certains appellent métier se comportent comme s'ils étaient imbriqués dans la même transaction, c'est-à-dire que si un appel échoue alors je devrai faire un rollback de toute les transactions (même celles réussies!). Bref pour ceux qui connaissent un peu ce concept, il s'agit de mettre en place un commit à n phases.
Est-ce que quelqu'un à une bonne adresse pour que je m'informe sur le sujet? Je suis également preneur de tout conseil ou suggestion!
La théorie J2EE veut que cela peut se faire simplement en utilisant l'objet javax.transaction.UserTransaction, appeler begin(), faire les appels aux différentes méthodes des EJB, puis appeler commit() ou rollback().
Dans la pratique, cela ne marche pas. Cela est effectivement très complexe à implémenter dans le meilleur des cas, et les performances sont très mauvaises, donc par défaut, ce type de fonctionnement est rarement activé et configuré, à condition que cela soit supporté par le containeur J2EE...
En effet, il faut pour que cela marche: 1) Un moniteur transactionnel avec une interface JTA 2) Que les différents composants EJB participant à la transaction soit configuré pour utiliser ce moniteur transctionnel. 3) Que les bases de données participants à la transactions soit configurées pour utiliser le commit à 2 phases avec ce moniteur transactionnel. 4) Que tu aies accès à l'object javax.transaction.UserTransaction
Note: je peux déjà dire que WAS ne supporte pas (4) dans Tomcat...
En fait, je conseille fortement de rechercher d'autres alternatives. Elles sont plus compliquées à programmer, mais plus facile à configurer et offrent de bien meilleures performances. Une option est d'utiliser des queues de messages persistants avec JMS.
Un cas classique: transfert d'argent. Un compte est débité sur une machine, l'argent est envoyé avec un message persistant vers l'autre machine qui va le créditer sur le compte destinataire.
L'intérêt de JMS (implémenté par WebSphere MQ dans WAS) est que: - le message n'est créé que si la transaction "débit" est réussie - le système guarantie que le message sera transmis (c'est aussi fiable qu'une base de donnée) - le message ne sera retiré de la queue que si la transaction "crédit" réussie.
L'aspect complexe est qu'il faut gérer les messages dont la transction "crédit" échoue (comme le renvoyer à l'originateur). Il faut accepter aussi la limitation que l'argent n'est pas disponible pendant le transfert du message. Cela n'est pas aussi problèmatique que cela semble. En effet, utiliser un commit à deux phases au lieux d'un message peut provoquer un problème plus grand, car si un problème arrive pendant le commit, les deux comptes sont bloqués tant que la transaction n'est pas résolue (complètement committée ou complètement rollbackée). Ai-je dis que les transactions globales ont des problèmes de performance?
-- Frédéric Lachasse - ECP86
Jacques-Olivier Haenni
Bonjour,
La solution proposée faisant intervenir une queue JMS pour découpler les deux bases de données est effectivement intéressante, mais n'évite pas le problème du commit à deux phases.
En effet, lorsqu'il est écrit, par exemple:
- le message n'est créé que si la transaction "débit" est réussie
cela indique qu'une transaction unique contrôle l'accès à la DB et à la queue JMS. Cela est réalisé par une transaction XA (2-phase commit).
Pour que cela fonctionne correctement, il faut d'ailleurs utiliser un driver XA pour la base de données (WAS sait accéder en XA aux queues JMS).
La solution proposée ne permet donc pas d'éviter un commit à deux phases, mais elle permet de confiner ces transactions XA à l'intérieur de chacun des WAS, ce qui est plus facile à mettre en oeuvre.
Jacques-Olivier
Frédéric Lachasse wrote: [...début du message coupé...]
En fait, je conseille fortement de rechercher d'autres alternatives. Elles sont plus compliquées à programmer, mais plus facile à configurer et offrent de bien meilleures performances. Une option est d'utiliser des queues de messages persistants avec JMS.
Un cas classique: transfert d'argent. Un compte est débité sur une machine, l'argent est envoyé avec un message persistant vers l'autre machine qui va le créditer sur le compte destinataire.
L'intérêt de JMS (implémenté par WebSphere MQ dans WAS) est que: - le message n'est créé que si la transaction "débit" est réussie - le système guarantie que le message sera transmis (c'est aussi fiable qu'une base de donnée) - le message ne sera retiré de la queue que si la transaction "crédit" réussie.
L'aspect complexe est qu'il faut gérer les messages dont la transction "crédit" échoue (comme le renvoyer à l'originateur). Il faut accepter aussi la limitation que l'argent n'est pas disponible pendant le transfert du message. Cela n'est pas aussi problèmatique que cela semble. En effet, utiliser un commit à deux phases au lieux d'un message peut provoquer un problème plus grand, car si un problème arrive pendant le commit, les deux comptes sont bloqués tant que la transaction n'est pas résolue (complètement committée ou complètement rollbackée). Ai-je dis que les transactions globales ont des problèmes de performance?
Bonjour,
La solution proposée faisant intervenir une queue JMS pour découpler les
deux bases de données est effectivement intéressante, mais n'évite pas
le problème du commit à deux phases.
En effet, lorsqu'il est écrit, par exemple:
- le message n'est créé que si la transaction "débit" est réussie
cela indique qu'une transaction unique contrôle l'accès à la DB et à la
queue JMS. Cela est réalisé par une transaction XA (2-phase commit).
Pour que cela fonctionne correctement, il faut d'ailleurs utiliser un
driver XA pour la base de données (WAS sait accéder en XA aux queues JMS).
La solution proposée ne permet donc pas d'éviter un commit à deux
phases, mais elle permet de confiner ces transactions XA à l'intérieur
de chacun des WAS, ce qui est plus facile à mettre en oeuvre.
Jacques-Olivier
Frédéric Lachasse wrote:
[...début du message coupé...]
En fait, je conseille fortement de rechercher d'autres alternatives. Elles
sont plus compliquées à programmer, mais plus facile à configurer et offrent
de bien meilleures performances. Une option est d'utiliser des queues de
messages persistants avec JMS.
Un cas classique: transfert d'argent. Un compte est débité sur une machine,
l'argent est envoyé avec un message persistant vers l'autre machine qui va
le créditer sur le compte destinataire.
L'intérêt de JMS (implémenté par WebSphere MQ dans WAS) est que:
- le message n'est créé que si la transaction "débit" est réussie
- le système guarantie que le message sera transmis (c'est aussi fiable
qu'une base de donnée)
- le message ne sera retiré de la queue que si la transaction "crédit"
réussie.
L'aspect complexe est qu'il faut gérer les messages dont la transction
"crédit" échoue (comme le renvoyer à l'originateur). Il faut accepter aussi
la limitation que l'argent n'est pas disponible pendant le transfert du
message. Cela n'est pas aussi problèmatique que cela semble. En effet,
utiliser un commit à deux phases au lieux d'un message peut provoquer un
problème plus grand, car si un problème arrive pendant le commit, les deux
comptes sont bloqués tant que la transaction n'est pas résolue (complètement
committée ou complètement rollbackée). Ai-je dis que les transactions
globales ont des problèmes de performance?
La solution proposée faisant intervenir une queue JMS pour découpler les deux bases de données est effectivement intéressante, mais n'évite pas le problème du commit à deux phases.
En effet, lorsqu'il est écrit, par exemple:
- le message n'est créé que si la transaction "débit" est réussie
cela indique qu'une transaction unique contrôle l'accès à la DB et à la queue JMS. Cela est réalisé par une transaction XA (2-phase commit).
Pour que cela fonctionne correctement, il faut d'ailleurs utiliser un driver XA pour la base de données (WAS sait accéder en XA aux queues JMS).
La solution proposée ne permet donc pas d'éviter un commit à deux phases, mais elle permet de confiner ces transactions XA à l'intérieur de chacun des WAS, ce qui est plus facile à mettre en oeuvre.
Jacques-Olivier
Frédéric Lachasse wrote: [...début du message coupé...]
En fait, je conseille fortement de rechercher d'autres alternatives. Elles sont plus compliquées à programmer, mais plus facile à configurer et offrent de bien meilleures performances. Une option est d'utiliser des queues de messages persistants avec JMS.
Un cas classique: transfert d'argent. Un compte est débité sur une machine, l'argent est envoyé avec un message persistant vers l'autre machine qui va le créditer sur le compte destinataire.
L'intérêt de JMS (implémenté par WebSphere MQ dans WAS) est que: - le message n'est créé que si la transaction "débit" est réussie - le système guarantie que le message sera transmis (c'est aussi fiable qu'une base de donnée) - le message ne sera retiré de la queue que si la transaction "crédit" réussie.
L'aspect complexe est qu'il faut gérer les messages dont la transction "crédit" échoue (comme le renvoyer à l'originateur). Il faut accepter aussi la limitation que l'argent n'est pas disponible pendant le transfert du message. Cela n'est pas aussi problèmatique que cela semble. En effet, utiliser un commit à deux phases au lieux d'un message peut provoquer un problème plus grand, car si un problème arrive pendant le commit, les deux comptes sont bloqués tant que la transaction n'est pas résolue (complètement committée ou complètement rollbackée). Ai-je dis que les transactions globales ont des problèmes de performance?
Sylvain Laurent
"Frédéric Lachasse" wrote in message news:XqcGd.2972$
Note: je peux déjà dire que WAS ne supporte pas (4) dans Tomcat...
J'étais justement en train d'essayer de faire ça: démarquer des transactions depuis tomcat lors d'appels de beans sur Websphere.
J'avais cru y être arriver : En faisant un lookup de "jta/usertransaction" au lieu de "java:comp/UserTransaction" pour récupérer l'objet UserTransaction. Ensuite ça avait l'air de marcher normalement: les appels à begin, commit et rollback ne faisaient pas d'erreur.
Sauf que l'appel à rollback ne fait pas de rollback de la transaction !!!
Donc effectivement, pas de transactions démarquée par le client depuis tomcat vers WAS :-(
Sylvain
"Frédéric Lachasse" <frederic.lachasse@verizon.net> wrote in message
news:XqcGd.2972$Vx2.121@trndny01...
Note: je peux déjà dire que WAS ne supporte pas (4) dans Tomcat...
J'étais justement en train d'essayer de faire ça: démarquer des transactions
depuis tomcat lors d'appels de beans sur Websphere.
J'avais cru y être arriver : En faisant un lookup de "jta/usertransaction"
au lieu de "java:comp/UserTransaction" pour récupérer l'objet
UserTransaction.
Ensuite ça avait l'air de marcher normalement: les appels à begin, commit et
rollback ne faisaient pas d'erreur.
Sauf que l'appel à rollback ne fait pas de rollback de la transaction !!!
Donc effectivement, pas de transactions démarquée par le client depuis
tomcat vers WAS :-(
"Frédéric Lachasse" wrote in message news:XqcGd.2972$
Note: je peux déjà dire que WAS ne supporte pas (4) dans Tomcat...
J'étais justement en train d'essayer de faire ça: démarquer des transactions depuis tomcat lors d'appels de beans sur Websphere.
J'avais cru y être arriver : En faisant un lookup de "jta/usertransaction" au lieu de "java:comp/UserTransaction" pour récupérer l'objet UserTransaction. Ensuite ça avait l'air de marcher normalement: les appels à begin, commit et rollback ne faisaient pas d'erreur.
Sauf que l'appel à rollback ne fait pas de rollback de la transaction !!!
Donc effectivement, pas de transactions démarquée par le client depuis tomcat vers WAS :-(
