Spring Batch JobRepository démuni

Question

J'utilise Spring Batch pour un système qui fait beaucoup d'opérations par lots.
J'utilise SimpleJobRepository avec en mémoire OTI.
Je voudrais savoir s'il y a un moyen d'éviter d'utiliser un JobRepository? quelque chose de similaire au gestionnaire de transaction démunie?
La raison que je demande est que le système doit fonctionner en permanence sans redémarrer et j'ai quelques préoccupations au sujet de la mémoire, il consommera.
Je sais que je peux utiliser une base JobRepositry de base de données, mais franchement, je ne ai pas vraiment besoin du tout.

S'il n'y a pas moyen de le faire, je vais apprécier si quelqu'un peut me rassurer sur le problème de la consommation de mémoire.

Merci.

Answer 1

Vous devez utiliser référentiel d'emploi car il contient les informations sur le contexte de l'emploi. la solution pour votre cas est - votre référentiel travail avec scope = « prototype » cela cérat une nouvelle dao en mémoire (mise en œuvre de la carte) pour chaque emploi, et donc pas de problème de mémoire. les frais généraux de création d'une nouvelle instance à chaque fois est dénué de sens en termes d'emplois par lots.

Answer 2

en mémoire la mise en œuvre présente un inconvénient majeur:. Vous ne pouvez pas utiliser multithreading dans vos batchs

Vous devez donc utiliser un référentiel de base de données. Je vous suggère d'utiliser H2 SQL: il est une base de données intégrée très léger. Nous l'utilisons pour nos tests unitaires.

Il fonctionne très bien avec Hibernate.

L'avantage de cette méthode sur celui de Ben est de vous connecter à la base de données de mémoire vous pour vérifier les statuts d'emplois (et la date de lancement, etc ...).

Answer 3

Je pense que tant que mon code de traitement par lots est thread-safe, il ne devrait pas d'importance si le dépôt est en mémoire ou base de données. Oui, vous risquez de perdre certains des avantages de regroupement que vous pouvez obtenir si vous utilisez DB mais si je ne dispose que d'un lot d'emploi en cours d'exécution sur mon serveur et son utilisation de filetage multiple pour faire son travail, qui devrait être bien.