fév 03

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 ?
  2. 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).

  3. Avez-vous une gestion de la Persistance ‘Maison’ ?
  4. 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.

  5. Envie de paralléliser des exécutions de requêtes SQL ?
  6. 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).

7 Responses to “Spring Batch : les pièges à éviter”

  1. Alexis B. dit :

    Bonjour,
    je me permets de réagir à votre article très intéressant sur Spring Batch pour vous poser la question suivante :
    - Je suis d’une application web dont certains actions (synchrones) peuvent entrainer des temps d’attente importante : je suis souhaiterai désynchronisé ce type de tâche pour permettre à l’utilisateur de reprendre la main et continuer à exécuter ce traitement lourd (ex : production de documents Xls ou Pdf en tâche de fond) => Spring Batch peut-il être le bon choix en considérant un nombre d’utilisateur important et une nécessaire de maitrisé le nombre de task en paralèlle ?
    Merci de votre retour.

  2. Bonjour,
    je vous conseillle plutôt d’utiliser la combinaison Runnable / TaskExecutor (dispo depuis le jdk 1.5).
    Mettez le lancement de votre code métier dans un Runnable, puis exécutez le par un taskExecutor (plusieurs au choix).
    La config du TaskExecutor vous permet de gérer les threads dispos (même changeable à chaud par JMX), ainsi que le comportement de celui-ci : parallélisation, avec ou sans file d’attente, etc …

  3. mouradski dit :

    Interessant,

    Merci pour ce partage

  4. Komi dit :

    Bonjour, j’aimerais avoir votre expertise sur un problème que je rencontre actuellement.
    j’aimerais faire une sauvegarde complète de ma base de donnée avec spring batch.
    mais les requetes ne permettent que de lire les données d’une table a la fois,comment m’y prendre pour recuperer les donnes de toutes les tables??
    merci d’avance pour vos reponses

  5. Bonjour,
    je suppose que tu veux extraire les données des tables. Pour cela, je te conseille un Reader qui va lire en base la liste des tables à archiver (via les metadata). Ensuite chaque nom de table sera passé à un Processor qui va faire un select * dans la table pour récupérer les données.
    Il faut que tu écrives un service qui va devoir enregistrer le résultats de ces requêtes sous un format archivable (par exemple format csv dans un fichier) Cet archivage sera fait dans un 2ième processor.
    Finalement, le dernier Writer n’a rien besoin de faire.

    Pour paralléliser l’extraction des données, il faut que tu parallélise l’étape Processor : le Reader sera unique (il dépile la liste des tables à archiver), mais les Processor bossent en parallèle. Donc à un moment T, tu auras plusieurs requêtes d’archivage en cours.
    Pour ce parallélisme, fais attention à ce que la partie Archivage soit bien thread-safe : il ne faut pas enregistrer dans un fichier des données mélangées provenant de différentes tables. Cette partie dépendra de ta stratégie d’archivage : fichier plat, insertion dans une base backup, etc …

  6. hadjila dit :

    Bonsoir,
    Tout d’abord merci pour vos conseille, cependant je viens vous poser une question concernant spring batch.
    j’aimerais relancer un job quand il est failed ou bien quand il est suspendu qu’il puisse reprendre là ou il c’était arrêté.
    J’utilise comme ordonnanceur quartz.

    Merci à vous

  7. mohcine dit :

    Bonjour, j’ai un petit soucis, je suis débutant en spring barch et je souhaiterai exécuter une requête sql. Cette requete sql vérifie l’environnement et en fonction du résultats elle renvoie une certaine phrase, “Ok” si l’environnement est vérifier, ” KO” dans le cas contraire, et en fait j’aimerai exécuter un log pour me dire si la requête est passé ou pas

    Je sais comment passé ma requête en paramêtre

    mais je ne sais pas récupérer les données,

    merci à vous =)

Leave a Reply


Creative Commons License
Blog Infin-It par Infin-It est mis à disposition selon les termes de la licence Creative Commons Paternité-Pas d'Utilisation Commerciale 2.0 France.