Discussion :

[grunt2000]

Bonjour,

J'ai un serveur A qui possède un @Service Spring dont une méthode veut appeler un web-service SOAP situé sur un autre serveur B. Ce serveur B est aussi en Spring.
Si toutes les parties se déclarent @Transactional, est-ce que A va pouvoir appeler le web-service de B, celui-ci réussir et - parce que ça lui chante - A au retour de l'appel du web-service et avant de quitter la fonction où cet appel a eu lieu, faire un setRollbackOnly() sur la transaction et annuler ce que B a fait ?

Ca m'arrangerait bien s'il m'était possible d'avoir ce comportement.

Merci !

Grunt.

[fr1man]

A mon avis c'est impossible.
Tes 2 serveurs ne peuvent pas etre dans le meme contexte transactionnel.
Donc, à part le gérer à la main, je ne vois pas.

[grunt2000]

J'espérais que ce soit devenu possible avec les container d'aujourd'hui.
Ce que j'ai lu dans un document J2EE - mais je pense que c'est Java et non JEE qui est porteur de l'avancement - c'est qu'il existe désormais un commit à "trois" phases.

C'est à dire :
1) Le commit à deux phases classique lié au fait que le périmètre d'une transaction est sur une méthode de service et les méthodes de service que celle-là appelle par composition, engageant une ou plusieurs de bases XA impliquées.

2) Le fait que le client est - depuis Java 6, je crois - considéré comme ayant son propre container : le container client, et dans l'absolu il est devenu possible de faire (sur le papier, hein ! je n'ai pas essayé !) ceci :
- Côté client je crée un batch qui appelle une dizaine de méthodes différentes de plusieurs services différents. Et tout se passe bien.
- Et puis, je décide finalement de tout annuler, et je fais un rollback depuis mon container client.

Ayant lu cela, rien ne semblait réclamer que les méthodes de services dûssent nécessairement être appelées sur le même serveur Spring, et le client pouvait selon moi joindre un serveur A puis B puis C si cela lui agréait.
Par ailleurs, je me disais aussi que le fait qu'un service Spring soit présenté en tant que @Service ou avec une interface web-service supplémentaire ne changeait rien à la manière dont il allait accepter les transactions.

Donc, en théorie, je voyais cela faisable.
Tout dépend de la justesse de ce que j'ai lu sur la réalité container client et sa capacité de distribuer des contexte transactions. S'il le fait comme c'est prétendu, tout devrait être réglé.