Spring batch est-il toujours la bonne solution pour les traitements de masse ?

**Zineb2014** · 22/12/2015, 10h41

Bonjour à tous,

J'ai un traitement en masse mais un peu complexe ( avec des préparations de données pour insertion dans des tables diverses) ,on m'a conseillé spring batch mais j'ai peur que la complexité des traitements ne favorise l'exploitation de ses performances ?!
Votre conseil SVP.

**Lordsephiroth** · 22/12/2015, 12h27

Bonjour,

En résumé : oui.

Pour plus de détails, j'ai participé pendant 2 ans à la migration d'une application de batchs COBOL d'une grande complexité (300'000 lignes de code COBOL, environ 150'000 lignes java après migration sans compter les XML spring batch). Le responsable de la version COBOL, qui est maintenant heureux retraité, doutait fortement de la capacité de Java à rivaliser avec des performances COBOL. Résultat : temps de traitement divisé par deux. Spring Batch est une solution très robuste et ultra performante pour la gestion des batchs.

Par contre, il faut être très vigilant lors de la réalisation de tels batchs. Il faut toujours penser que la technologie Spring Batch traite les éléments "par chunk" et qu'à aucun moment il ne faut tenter de lire une source de données par un composant qui n'est pas prévu pour. Typiquement, j'ai déjà vu des readers XML utilisé en Spring Batch qui effectuaient une lecture par un simple "load" JAXB. Résultat : le fichier XML entier chargé en une fois -> OutOfMemory. Petit truc quand je développe un batch, je me pose cette question : si mon nombre d'élément en entrée est de l'ordre du milliard et non du million, mon traitement se terminera-t-il un jour ?

Il faut également être vigilant sur certaines questions comme la gestion de la transaction (notamment, l'utilisation de Web Services, qui ne sont pas des protocoles XA, peuvent poser d'énormes problèmes de consistance des données, expérience personnelle en production). Un autre point à respecter : les traitements coûteux, notamment les IO, doivent TOUS être réalisés en mode "par chunK". Inutile de lire 100 éléments dans un bloc si on écrit en base de données en utilisant une fonction "persist" d'une DAO Hibernate pour chaque objet de la liste.

Ce mode de traitement complexifie certains traitements. Les tris et les agrégations d'objets sont assez pénibles à réaliser.

Dernier conseil de ma part : ne pas utiliser Hibernate sur une grappe d'objets complexes. La lecture peut être optimisée, mais je n'ai jamais réussi à écrire suffisamment vite avec cette technologie (stale entities check, ce genre de choses coûtent très cher). Ma dernière expérience en termes de performances : lecture de 50'000 contrats en assurance vie (objets complexes) avec hibernate (en optimisant au max) : 2 minutes. Écriture de ces même contrats avec Hibernate : 4h. Écriture par des requêtes JDBC natives : 10 minutes.