Projet

Général

Profil

Actions

Bug #13415

fermé

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

Ajouté par Yohann Chastagnier il y a environ un an. Mis à jour il y a environ un an.

Statut:
Closed
Priorité:
High
Assigné à:
Début:
09/01/2023
Echéance:
% réalisé:

100%

Temps estimé:
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

Formats disponibles : Atom PDF