asynchrone JMS lock

salut

une question d'ordre général

j'ai une appli constitué de deux modules que nous appellerons front et back.

Le front reçoit des objets, exécute un ensemble de traitements, le stocke en base, envoie un message JMS vers le back et commit sa transaction XA.

Le back scan les queues JMS le concernant et récupère des identifiants d'objets dans le message. Il tente un load de l'objet et c'est là qu'il y a problème car il arrive que le back tente de charger un objet que le front n'a pas encore commité.


j'ai essayé plusieurs solution qui ne me conviennent pas :

- une transaction externe dans le front pour créer l'objet dans la base de données suivi d'un load dans le front avec un lock. Le back reçoit le message et tente un load lock mais il est mis en attente le temps que le front commit sa transaction. Le problème de cette solution c'est que les verrous en bdd augmentent et je me retrouve toujours avec un "fond de roulement" de messages verrouillés.

pour faire simple je souhaiterais que le back ne tente un load que lorsque le front a terminer sa transaction et pas avant. Mais je vois pas comment le faire simplement.

merci

commiter et envoyer le message après serait la meilleure des solutions, mais je suppose que c'est pas simple ? La clôture transactionnelle est dans l'appelant ?

Citation:

---

Envoyé par Tommy31

commiter et envoyer le message après serait la meilleure des solutions, mais je suppose que c'est pas simple ? La clôture transactionnelle est dans l'appelant ?

---

oui c'est le front qui clôture la transaction et donc relache le verrou base
c'est exactement ce que je cherche à faire (envoyer le message après la transaction) mais je ne vois pas comment

Tu n'as le choix.
Tu dois:
* créer une transaction de type XA qui englobe la BDD et JMX
* verrouiller ta base de données BDD (ex Oracle select id from table for Update) . Ce verrou sera libéré par le commit de la branche XA-BaseDeDonneé.
Le commit XA-JMS déverouillera le message qui sera du coup disponible pour ton MDB.

Ceci garantie une intégrité transactionnelle de l'ensemble sans pour dégradé les performance.

J'ai eu le cas d'une application ou il n'y avait pas de verrou sur les données et le commit 'JMS' allait plus vite que le commit 'BDD' (si si !!), ce qui engendrait la lecture de données incohérentes (version précédente, commitées précédemment).

Citation:

---

Tu n'as le choix.
Tu dois:
* créer une transaction de type XA qui englobe la BDD et JMX
* verrouiller ta base de données BDD (ex Oracle select id from table for Update) .

---

pour le select for update, y a pas de soucis c'est ce que je fais
par contre le fait d'englober JMS dans la transaction XA me posais un problème car je pensais (est ce vrai?) que d'inclure JMS dans la transaction aurait pour effet de ralentir l'ensemble puisque on devait attendre que le message JMS soit arrivé pour commiter la transaction et donc d'être plus lent globalement.

Citation:

---

Envoyé par bmoussaud

J'ai eu le cas d'une application ou il n'y avait pas de verrou sur les données et le commit 'JMS' allait plus vite que le commit 'BDD' (si si !!), ce qui engendrait la lecture de données incohérentes (version précédente, commitées précédemment).

---

je te crois, j'ai eu un cas similaire où l'émetteur qui envoyait le message commitait sa transaction après que le récepteur l'ai lu

Citation:

---

Envoyé par austin P.

pour le select for update, y a pas de soucis c'est ce que je fais
par contre le fait d'englober JMS dans la transaction XA me posais un problème car je pensais (est ce vrai?) que d'inclure JMS dans la transaction aurait pour effet de ralentir l'ensemble puisque on devait attendre que le message JMS soit arrivé pour commiter la transaction et donc d'être plus lent globalement.

---

La transaction XA[JMS+BDD] est la solution qui va garantir un tout ou rien, tout commit ou tout rollback.
Dans le cas d'un serveur JMS, un commit d'un message JMS consiste globalement à rendre disponible le message à un éventuel consommateur, il n'implique en aucun cas sa consommation.

Suivant les implémentations du serveurs, le commit équivaut à
* persister le message (si nécessaire)
* passer un flag='true' qui indique que le message peut être consommé (tres rapide !)

Donc la mise en place d'une transaction XA va:
* garantir une intégrité transactionnelle
* ne pas pénaliser les performances.

ok ca fonctionne avec le mode acknowledge DUPS_OK_ACKNOWLEDGE