Quand tu as deux transactions avec deux resources managers, l'algo n'est pas du tout diabolique. En particulier dans le cas de la lecture d'un message JMS et l'écriture en base. En gros :
- début transaction JMS, lecture du message
- début transaction base de données
- traitement...
- si tout va bien : commit base de données puis commit broker JMS
- si tout va mal : rollback des deux.
Bon, maintenant, le pire cas, que se passe-t-il quand, pas de pot (cas rare, mais qui peu exister) ton serveur meurt lamentablement entre les deux commits. Cela fait que ta transaction en base est validée, mais ta transaction avec ton broker est en rollback. Donc, à la prochaine exécution ton code lira pour la seconde fois le même message. Soit ce n'est pas gênant (youpi), soit c'est un problème, dans ce cas il faut pouvoir le gérer (identifiant fonctionnel, etc.).
Simple à coder, simple à débugguer. Pas de dépendance sur des trucs compliqués. Pas de risque de tout casser lors d'un patch ou d'une montée de version (du moins pas à ce niveau :-)).
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
Quand tu as deux transactions avec deux resources managers, l'algo n'est pas du tout diabolique. En particulier dans le cas de la lecture d'un message JMS et l'écriture en base. En gros :
- début transaction JMS, lecture du message
- début transaction base de données
- traitement...
- si tout va bien : commit base de données puis commit broker JMS
- si tout va mal : rollback des deux.
Bon, maintenant, le pire cas, que se passe-t-il quand, pas de pot (cas rare, mais qui peu exister) ton serveur meurt lamentablement entre les deux commits. Cela fait que ta transaction en base est validée, mais ta transaction avec ton broker est en rollback. Donc, à la prochaine exécution ton code lira pour la seconde fois le même message. Soit ce n'est pas gênant (youpi), soit c'est un problème, dans ce cas il faut pouvoir le gérer (identifiant fonctionnel, etc.).
Simple à coder, simple à débugguer. Pas de dépendance sur des trucs compliqués. Pas de risque de tout casser lors d'un patch ou d'une montée de version (du moins pas à ce niveau :-)).