Camunda Optimistic Locking Exception — Cause Racine et Solution
Camunda Optimistic Locking Exception — Cause Racine et Solution
Introduction
Si vous travaillez avec Camunda BPM, vous rencontrerez tôt ou tard une erreur appelée OptimisticLockingException.
Beaucoup de développeurs pensent immédiatement qu’il s’agit d’un bug dans le moteur BPM. En réalité, cette exception est un mécanisme normal de protection contre les conflits de concurrence dans la base de données.
Dans cet article, nous allons expliquer :
Ce qu’est Optimistic Locking dans Camunda
Les causes réelles de l’exception
Les situations courantes où elle apparaît
Les solutions pratiques pour la corriger
Qu’est-ce que l’Optimistic Locking dans Camunda ?
Camunda utilise le verrouillage optimiste (Optimistic Locking) pour éviter que plusieurs transactions modifient la même donnée en même temps.
Si deux transactions essaient de modifier la même ligne dans la base de données, l’une réussit et l’autre échoue avec une OptimisticLockingException.
Ce mécanisme protège le moteur BPM contre :
les mises à jour perdues
les incohérences de données
les conflits d’exécution parallèle
En résumé :
Deux transactions → même donnée → une seule peut réussir.
Cause principale de l’exception
La cause principale est la modification concurrente de la même entité dans la base de données.
Dans Camunda, chaque enregistrement possède un numéro de version appelé :
REV_
Le fonctionnement est le suivant :
Deux transactions lisent la même ligne avec REV = 1
La première transaction met à jour la ligne → REV devient 2
La seconde transaction tente de mettre à jour REV = 1
Camunda détecte le conflit et lance OptimisticLockingException
Cela permet de garantir la cohérence des données du processus.
Situations où cette exception apparaît souvent
1. Parallel Gateway (Synchronisation)
C’est le cas le plus fréquent.
Lorsque deux branches parallèles se terminent exactement au même moment, elles essaient toutes les deux de mettre à jour la même exécution du processus.
Dans ce cas :
une transaction réussit
l’autre déclenche OptimisticLockingException.
2. Compléter la même tâche deux fois
Exemple :
L’utilisateur clique sur Complete Task
La requête réseau est lente
L’utilisateur clique une deuxième fois
Deux transactions concurrentes sont exécutées
Une transaction réussit et l’autre échoue avec l’exception.
3. Tâches parallèles modifiant la même variable
Exemple BPMN :
Parallel Gateway
/ \
Service A Service B
\ /
Si les deux services modifient la même variable de processus, un conflit peut apparaître.
4. Multi-Instance Tasks
Dans les activités multi-instances, Camunda met à jour des variables internes comme :
nrOfCompletedInstances
nrOfActiveInstances
Si plusieurs instances se terminent simultanément, une exception peut être déclenchée.
Comment Camunda gère cette exception
Dans beaucoup de cas, Camunda gère automatiquement l’exception.
Si une tâche est exécutée par le Job Executor, le moteur effectue automatiquement un retry de la transaction.
Cela signifie que :
la transaction échoue
Camunda relance automatiquement l’exécution
Donc dans beaucoup de cas, cette exception est normale et attendue.
Solutions pratiques
1. Utiliser Async Continuations
Ajouter :
Async Before
Async After
Cela crée une frontière de transaction et réduit les conflits.
2. Utiliser des variables locales
Au lieu de :
setVariable("status")
Utilisez :
setVariableLocal("status")
Cela réduit les conflits entre branches parallèles.
3. Éviter les mises à jour simultanées
Si plusieurs tâches modifient la même donnée :
Préférez un flux séquentiel plutôt que parallèle.
4. Utiliser Exclusive Jobs
Les exclusive jobs empêchent plusieurs tâches du même processus de s’exécuter en parallèle.
Exemple réel
Considérons un processus e-commerce :
Receive Order
|
Parallel Gateway
/ \
Check Stock Process Payment
\ /
Join Gateway
|
Confirm Order
Si Check Stock et Process Payment se terminent au même moment, le join gateway peut déclencher l’exception.
La solution consiste souvent à ajouter Async Before sur le join gateway.
Bonnes pratiques pour les développeurs Camunda
✔ Éviter les modifications parallèles des mêmes variables
✔ Utiliser les async continuations
✔ Concevoir des processus BPMN optimisés
✔ Implémenter une stratégie de retry
✔ Surveiller les logs du moteur
Recommandations (Articles à lire)
Si vous voulez approfondir Camunda, BPMN et l’automatisation des workflows, consultez aussi mes articles :
📚 Articles recommandés :
👉 https://shikhanirankari.blogspot.com/search/label/French
Vous y trouverez des guides sur :
Camunda BPM pour débutants
BPMN Workflow Design
Debugging des processus Camunda
Optimisation des performances BPM
Conclusion
L’OptimisticLockingException dans Camunda n’est généralement pas une erreur critique.
C’est un mécanisme de protection contre les conflits de concurrence qui garantit l’intégrité des données du processus.
En comprenant :
les causes
les situations où elle apparaît
les bonnes pratiques de modélisation BPMN
vous pourrez concevoir des workflows plus robustes et scalables.
✅ Si vous apprenez Camunda, BPMN et l’automatisation des processus, suivez mon blog pour plus de tutoriels techniques.
💼 Support professionnel disponible
Si vous rencontrez des problèmes sur des projets réels liés au développement backend d’entreprise ou à l’automatisation des workflows, je propose des services de conseil payants, de débogage en production, de support projet et de formations ciblées.
Les technologies couvertes incluent Java, Spring Boot, PL/SQL, Azure, CMS, ainsi que l’automatisation des workflows (jBPM, Camunda BPM, RHPAM, Flowable).
📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 Website: IT Trainings | Digital lectern | Digital rostrum | Digital metal podium
Comments
Post a Comment