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.
Tout a fait.
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.
Oui, oui, mais puisqu'il faut tester toute la stack de toute maniere...
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.
Ca commence souvent en parvenant a tenir dans une seule transaction, puis au cours du temps, les volumes augmentent, les requirements changent et/ou s'amoncellent finissant par provoquer des incidents de production P1 dans des cas patologiques. Il faut alors changer l'architecture du logiciel sur cette partie.
Je suis d'accord qu'avoir une scope de transaction enorme est une mauvaise idee en theorie, mais en pratique si ton appli fait 15000 choses (progiciel metier bien complexe) et que tu n'a pas le temps d'etudier la facon dont elle est utilisee, et bien tu pares au plus presse et tu fait le pompier de temps en temps. Bref je suis d'accord en theorie, mais selon l'environnement dans lequel tu travailles et selon les contraintes que tu as, ca n'est pas faisable en pratique.
Mais je trouve la discussion interessante. Merci beaucoup.
[^] # Re: Questions
Posté par djano . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 3.
Tout a fait.
Oui, oui, mais puisqu'il faut tester toute la stack de toute maniere...
Ca commence souvent en parvenant a tenir dans une seule transaction, puis au cours du temps, les volumes augmentent, les requirements changent et/ou s'amoncellent finissant par provoquer des incidents de production P1 dans des cas patologiques. Il faut alors changer l'architecture du logiciel sur cette partie.
Je suis d'accord qu'avoir une scope de transaction enorme est une mauvaise idee en theorie, mais en pratique si ton appli fait 15000 choses (progiciel metier bien complexe) et que tu n'a pas le temps d'etudier la facon dont elle est utilisee, et bien tu pares au plus presse et tu fait le pompier de temps en temps. Bref je suis d'accord en theorie, mais selon l'environnement dans lequel tu travailles et selon les contraintes que tu as, ca n'est pas faisable en pratique.
Mais je trouve la discussion interessante. Merci beaucoup.