Je trouve assez discutable techniquement le fait de faire tourner une JVM serveur/démon/serveur d'appli pour y faire tourner des batches lourds alors qu'il est beaucoup plus sûr techniquement de lancer une JVM pour chaque instance de batch lourd (pas de risque d'exploser le tas ou une autre ressource) et que le coût de démarrage d'une JVM en 2013 est juste ridicule (au regard d'un batch de plusieurs secondes ou plusieurs heures).
Sans parler de la souplesse que peut donner au développeur le fait d'être seul dans sa JVM (un commentateur parlait de SpringBatch plus haut, faire un batch avec SpringBatch dans une JVM dédiée c'est facile, ne pas se marcher sur les pieds quand plusieurs sont dans la JVM il faut réfléchir et se parler entre développeurs voire équipes).
Sinon bravo c'est super intéressant de gérer ce parent pauvre du monde Java qu'est le batch !
# de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 5.
Je trouve assez discutable techniquement le fait de faire tourner une JVM serveur/démon/serveur d'appli pour y faire tourner des batches lourds alors qu'il est beaucoup plus sûr techniquement de lancer une JVM pour chaque instance de batch lourd (pas de risque d'exploser le tas ou une autre ressource) et que le coût de démarrage d'une JVM en 2013 est juste ridicule (au regard d'un batch de plusieurs secondes ou plusieurs heures).
Sans parler de la souplesse que peut donner au développeur le fait d'être seul dans sa JVM (un commentateur parlait de SpringBatch plus haut, faire un batch avec SpringBatch dans une JVM dédiée c'est facile, ne pas se marcher sur les pieds quand plusieurs sont dans la JVM il faut réfléchir et se parler entre développeurs voire équipes).
Sinon bravo c'est super intéressant de gérer ce parent pauvre du monde Java qu'est le batch !