Tu comptes le surcoût de temps de réponse lors de l'exécution du traitement, et juste ce surcoût là j'imagine.
Non parce qu'il y a le surcoût de complexité, de maintenabilité (pas seulement de l'appli mais aussi de toute la stack middleware), etc. et ceux-là ne sont pas négligeables. Ou du moins ils ne le sont pas dès que tu as passé les 8 semaines après la première livraison de ton appli en prod.
De plus envisager d'utiliser XA en batch de façon automagique dans un MDB, c'est faire l'hypothèse que tout le traitement tient dans une transaction. Et en général pour un batch c'est impossible. Sans parler du fait que même quand ça rentre (par miracle) dans les ressources allouables sur la base et ailleurs, c'est une mauvaise idée d'avoir un scope de transaction énorme.
[^] # Re: Questions
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Tu comptes le surcoût de temps de réponse lors de l'exécution du traitement, et juste ce surcoût là j'imagine.
Non parce qu'il y a le surcoût de complexité, de maintenabilité (pas seulement de l'appli mais aussi de toute la stack middleware), etc. et ceux-là ne sont pas négligeables. Ou du moins ils ne le sont pas dès que tu as passé les 8 semaines après la première livraison de ton appli en prod.
De plus envisager d'utiliser XA en batch de façon automagique dans un MDB, c'est faire l'hypothèse que tout le traitement tient dans une transaction. Et en général pour un batch c'est impossible. Sans parler du fait que même quand ça rentre (par miracle) dans les ressources allouables sur la base et ailleurs, c'est une mauvaise idée d'avoir un scope de transaction énorme.