Suite à la mise en place de Spring Batch 2.1 chez un client, voici quelques recommandations afin d’éviter une catastrophe technique.

1. Est-ce que votre traitement est un Batch ?

Il faut savoir que Spring Batch a été développé dans la logique des Batchs tels qu’ils existaient dans les gros systèmes : un Batch est une répétition en très grand nombre d’opérations unitaires (work unit).
Le mode de fonctionnement de Spring Batch est très lié à ce modèle.
Il est donc complètement inutile de se lancer dans l’implémentation de ce framework si l’organisation de votre traitement ne suit pas ce modèle.
Je pense notamment à des traitements qui executeraient des updates SQL massifs : il ne sert à rien de construire une suite de Steps qui lanceront chacunes un update massif. Il faut construire une Step unique qui lancera un traitement complet sur un élément unitaire (appelé chunk dans le langage Spring Batch).

2. Avez-vous une gestion de la Persistance ‘Maison’ ?

Pour bénéficier de la puissance de Spring Batch, il est important que votre couche de persistance soit homogène : elle doit être full Hibernate, full iBatis ou full Spring JDBC et ne pas comporter d’éléments ‘homemade’.
La gestion des transactions dans le batch est déléguée au TransactionManager, le développeur n’a plus la main dessus.

3. Envie de paralléliser des exécutions de requêtes SQL ?

Attention !
Si vous souhaitez multithreader des requêtes potentiellement longues avec Spring Batch, il vous faudra mettre en place du JTA. En effet, votre TransactionManager va devoir gérer une transaction ‘chapeau’ qui gèrera elle-même une transaction par thread.
D’où JTA. Ceci est dû au fait qu’une connection à la base de données ne peut pas être accédée simultanément par plusieurs threads (l’objet Connection n’est pas thread-safe).