Bug #13415
ferméProblème transactionnel sur la synchronisation de calendriers avec événements récurrents
100%
Description
- Créer un agenda vide dans une service externe (Google par exemple)
- Récupérer le lien privé de ce calendrier
- Créer un agenda distant dans Silverpeas synchronisé sur le lien privé récupéré
- Modifier l'occurrence d'un événement sous-entend pour l'occurrence soit :
- d'ajouter un participant s'il n'en existe pas encore
- de retirer le participant s'il en existe déjà un
- Les occurrences d'un événement sont nommées par un numéro de sorte d'obtenir o1, o2, o3, ..., oN où o1 correspond à la première occurrence à la création de l'événement
- Se diriger sur le service distant
- Créer un événement au 4 janvier (par exemple) toute la journée et indiquer une récurrence toutes les semaines
L'occurrence au 4 janvier correspond donc à o1, celle du 11 janvier à o2 etc. - Depuis Silverpeas, réaliser une synchronisation manuelle
La synchronisation se réalise avec succès - Depuis le service externe
- supprimer o1
- modifier o2
- Depuis Silverpeas, réaliser une synchronisation manuelle
La synchronisation se réalise avec succès - Depuis le service externe
- modifier o2
- supprimer o3
Résultat obtenu :
La synchronisation semble être figée et la requête HTTP finit en erreur.
Résultat attendu
Aucune erreur avec prise en compte des modifications.
Complément
Il s'agit ici d'une problématique transactionnelle.
Les actions réalisées sur le service de calendrier externe juste avant la dernière synchronisation dans Silverpeas engendre une suppression totale des occurrences dans Silverpeas avant d'enregistrer les occurrences à mettre à jour.
Pour chaque mise à jour d'occurrence, le système cherche à connaître l'état de l'occurrence avant modification (donc hors transaction). Or, même si le traitement de select est réalisé dans une autre transaction, cette dernière est bloquée par la transaction principale (à cause des suppressions sur les données qui sont ciblées par le select de la nouvelle transaction). Si bien que le système se retrouve dans un interblocage de transaction.
A terme, le serveur se retrouve dans un état instable, voire complètement bloqué.