Project

General

Profile

Actions

Bug #13415

closed

Problème transactionnel sur la synchronisation de calendriers avec événements récurrents

Added by Yohann Chastagnier 23 days ago. Updated 22 days ago.

Status:
Closed
Priority:
High
Start date:
01/09/2023
Due date:
% Done:

100%

Estimated time:
Navigateur:
Tous
Votre version de Silverpeas:
6.3
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

Description

Pré-requis :
  • 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é
Définitions
  • 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, ..., oNo1 correspond à la première occurrence à la création de l'événement
Un cas de test
  1. Se diriger sur le service distant
  2. 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.
  3. Depuis Silverpeas, réaliser une synchronisation manuelle
    La synchronisation se réalise avec succès
  4. Depuis le service externe
    1. supprimer o1
    2. modifier o2
  5. Depuis Silverpeas, réaliser une synchronisation manuelle
    La synchronisation se réalise avec succès
  6. Depuis le service externe
    1. modifier o2
    2. 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é.

Actions #1

Updated by Yohann Chastagnier 22 days ago

  • Status changed from In progress... to Resolved
  • % Done changed from 0 to 100

Le cas découvert est maintenant pris en charge.

PR : https://github.com/Silverpeas/Silverpeas-Core/pull/1252

Actions #2

Updated by Miguel Moquillon 22 days ago

  • Status changed from Resolved to Integration in progress...
Actions #3

Updated by Miguel Moquillon 22 days ago

  • Status changed from Integration in progress... to Closed

Intégré dans les branches 6.3.x et master

Actions

Also available in: Atom PDF