Discussion :

[mickael.camelot]

Bonjour,

Comment écrire en base au moment du Read ?

Contexte :
J'ai un projet en base de données qui peut être sous différents états :
- A_FAIRE
- EN_COURS
- EN_ERREUR
- TERMINER

Un batch est chargé de récupérer les projets A_FAIRE et d'exécuter différents traitements.

Objectif :
L'objectif est de faire passer chaque projet en cours de traitement par le batch à EN_COURS dès que le projet est pris en charge par le batch.

Problème :
Spring batch effectue le commit uniquement après le write.
Le projet passe donc fonctionnelement de A_FAIRE, En_COURS, TERMINER correctement mais côté base de donné, le projet passe de A_FAIRE à TERMINER directement car la phase EN_COURS n'est pas commitée.

J'aurai souhaiter pouvoir dès le Read faire passer mon projet à EN_COURS en base de données.

avez vous une idée ?

cordialement

[tchize_]

Tu dois faire un commit pour que les données soient visible. Donc tu dois travailler, suivant ta logique, en plusieurs transaction
1) récupération d'un project et passage à en cours : commit
2) opérations sur le projet et passage à terminé: commit
3) passer au projet suivant.

[mickael.camelot]

Bonjour,

Merci pour votre réponse,

Cependant, le problème est qu'il peut potentiellement y avoir plusieurs batchs de lancés à intervalles réguliers. Les changements d'états du projet doivent donc se réaliser dans le step courant. 1 step, 3 états.
Si je suis votre raisonnement, des processus pourraient se chevaucher.

- Batch1 :
- Step 1
- Read : récupère le projet A_FAIRE
- Process : passage à EN_COURS
- Write : commit

- Batch1
- Step 2
- Read : récupère projet en cours
- Process : traitement
- Write : passage projet TERMINER

- Batch2
- Step2
- Read : récupère projet en cours
- Process : traitement
- Write : passage projet TERMINER

Comment le Batch2 pourrait il savoir que le projet récupéré n'est pas déjà en traitement par le batch1 ?

c'est pourquoi la gestion de l'état du projet doit être géré durant le Step.

Solution utilisée:
J'ai trouvé une solution paliative. Je ne sais pas si cela respecte la logique Spring batch.
J'ai instancé deux connexions. 1 pour le traitement du batch, et 1 pour la gestion de l'état du projet.

Ainsi lors du READ j'ai implémenté la méthode afterRead qui se charge de passer le projet récupéré à EN_COURS en utilisant une transaction différente de celle utilisée par le batch. Puis lors du WRITE j'ai implémenté la méthode afterWrite qui se charge de passer le projet à l'état TERMINER.

Ceci permet à deux batchs d'être exécutés à intervalles différents, et ceci sans le risque que deux batchs traitent le même projet.

[tchize_]

Comment le Batch2 pourrait il savoir que le projet récupéré n'est pas déjà en traitement par le batch1 ?

Parce que ce n'est pas lui qui l'a passé de A faire à en cours. C'est l'idée, celui qui fait passer à en cours endosse la responsabilité de le traiter dans la transaction suivante. C'est à peu près ce que tu met dans ta solution paliative qui a quand même quelques soucis.
Tes deux transactions de batch 1 manipulent le projet en // (begin begin commit commit) et non pas l'une à la suite de l'autre (begin commit, begin commit) => elles risquent de se marcher sur les pieds et déclencher une erreur dans le SGDB si elles tentent de manipuler les même row.

Pour que les autres process / autres batch voient les changements dans A faire -> En cours alors que tu n'a pas commit la transaction, tu a du diminuer le niveau d'isolation de tes transaction avec tous les problèmes qui vont avec (dirty read, phantom read, ...) ce qui n'est pas recommandé. Il est de loin préférable d'avoir autant que possible des transaction isolées en SERIALIZABLE.