Le fonctionnement des MDB pousse à utiliser JTA, faire des transactions XA entre plusieurs ressources manager (base de données et broker de message).
Dans les faits, c'est une galère pas possible à mettre en marche et de plus c'est horriblement lent. Il est préférable de gérer deux transactions séparés, manuellement (bean managed) et de gérer au niveau applicatif le cas d'un crash entre les deux commits (c'est à dire un doublon si les commits sont dans le bon ordre).
SprintBatch est compatible EE... cela veut dire deux framework de dév pour les développeurs. Et quid d'un morceau de code qui est utilisé à la fois en batch et en interactif ? C'est un peu mélanger l'eau et le feu.
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Le fonctionnement des MDB pousse à utiliser JTA, faire des transactions XA entre plusieurs ressources manager (base de données et broker de message).
Dans les faits, c'est une galère pas possible à mettre en marche et de plus c'est horriblement lent. Il est préférable de gérer deux transactions séparés, manuellement (bean managed) et de gérer au niveau applicatif le cas d'un crash entre les deux commits (c'est à dire un doublon si les commits sont dans le bon ordre).
SprintBatch est compatible EE... cela veut dire deux framework de dév pour les développeurs. Et quid d'un morceau de code qui est utilisé à la fois en batch et en interactif ? C'est un peu mélanger l'eau et le feu.