Bug #2738
fermé
Suppression d'un espace de la corbeille d'espace
100%
Description
Attention, une anomalie est survenue sur l'environnement Intranoo aujourd'hui. Cette anomalie n'est pas reproductible ni sur une version 5.7.3 ni sur une version 5.8-SNAPSHOT.
Cette anomalie doit être liée à l'historique des données dans un environnement particulier.
Ne pas reproduire le scénario suivant sur l'intranoo.
Scénario de l'anomalie
Cette anomalie est reproductible sur notre environnement intranoo.
1) Se connecter avec un compte Administrateur de la plateforme
2) Se rendre sur la corbeille d'espace
3) Supprimer définitivement de la corbeille l'espace "Test 5.5-SNAPSHOT" ainsi que l'application "TT brouillon + versioning + autres"
Résultat obtenu
L'espace ainsi que l'application sont toujours dans la corbeille d'espace.
Attention ceci n'est que la partie visible de l'anomalie. Une fois cette action réalisée, de gros disfonctionnement apparaissent sur l'application Silverpeas. En effet l'ensemble des GEDs deviennent inaccessibles. D'autres applications sont également inaccessibles sur la plateforme.
Les seules traces disponibles sont les suivantes:
07/12/11-10:37:02,592 - FATAL : WA238,ASP,1,2 07/12/11-10:37:02,592 - FATAL : ACP,kmelia989,1,2
Résultat souhaité
L'espace et l'application doivent être supprimés de la corbeille d'espace
Mis à jour par Nicolas Eysseric il y a presque 13 ans
- Statut changé de New à In progress...
- Assigné à mis à Anonyme
Mis à jour par Anonyme il y a presque 13 ans
Suite à une analyse du problème, lors de la suppression d'un espace contenant une application qui fait appel à la notion de noeud comme Kmelia par exemple, on aboutit à un lock de la table SB_Node_Node.
En effet une première partie de la suppression d'un composant indique la notion de transaction en base de données.
ligne 1305 de la class Admin : domainDriverManager.startTransaction(false);
Ensuite ligne 1342 de la même class :
componentManager.deleteComponentInst(componentInst, domainDriverManager);
Cette méthode aboutit à l'appel service.deleteAllPreDefinedClassifications(null, componentId);
qui récupère la liste des noeuds à supprimer :
PdcClassificationService getNodeBm().getAllNodes(new NodePK(null, instanceId))
Or la table contenant les noeuds a déjà eu des suppressions d'éléments ce qui bloquent la table SB_Node_Node. ( lors de la dés-instanciation dans NodeInstantiator.delete())
La conséquence de cela induit un blocage de la requête SQL et donc un lock sur la table SB_Node_Node car le traitement attend que la transaction se termine.
La requête sp_who2 permet de lister les requêtes en cours d'exécutions sur le serveur de base de données MS SQL Server.
53 SUSPENDED sa PORTEBO 63 Intranoo SELECT 1434 821 12/09 12:11:52 jTDS 53 0
Ensuite la colonne BlkBy nous donne l'identifiant de la transaction qui bloque la requête :
la requête suivante : dbcc inputbuffer(63)
permet d'obtenir la requête qui pose problème ici le résultat est le suivant :
delete from favorit where componentName =
Or cette requête est appelée juste après la suppression de l'instance dans la table SB_Node_Node.
(Voir Admin.uninstantiateComponents...)
Il faut que je test si la suppression deleteComponentInst peut être réalisée avant le unInstantiateComponents...
Mis à jour par Anonyme il y a presque 13 ans
Je vais lister ici toutes les pistes étudiées depuis hier:
- Level de compatibilité de la BD MS SQL Server
Test en version SQL Server Version 2000 (80)
Test en version SQL Server Version 2008 (100)
Aucun de ces modes ne résout le problème de blocage de la table
- Interversion de componentManager.deleteComponentInst et unInstantiateComponents dans la class Admin
Cela fonctionne dans le cas particulier d'un espace. Cependant sur la suppression d'autres espaces il apparaît d'autres dis-fonctionnements. Ces autres problèmes apparaissent lorsque l'on tente de supprimer des espaces qui ont des composants avec un profile spécifique.
- Release notes du driver JTDS 1.2.5 par rapport au 1.2.2 actuellement en service:
Normalement le driver JTDS n'a pas évolué sur l'accès concurrent sur une même table...
http://sourceforge.net/news/?group_id=33291
Mis à jour par Miguel Moquillon il y a presque 13 ans
- Statut changé de In progress... à Feedback
Etienne peux tu récupérer le code de ma branche node-deletion-notif-improve dans Silverpeas-Core et valider la correction avec MS SQLServer.
Mis à jour par Anonyme il y a presque 13 ans
- Statut changé de Feedback à In progress...
Récupération des sources de Miguel...
En cours
Mis à jour par Anonyme il y a presque 13 ans
Toujours des problèmes de lock sur la table SB_Node_Node.
Mis à jour par Anonyme il y a presque 13 ans
Miguel,
J'ai téléchargé les dernières sources sur ton repository GIT, buildé le projet (à noter des erreurs dans les tests sous Windows) et le problème de lock est toujours présent. Pourrais tu m'indiquer le modification que tu as réalisé ? Cela me permettrait de vérifier que j'ai récupéré le bon code source pour effectuer mes tests.
Mis à jour par Anonyme il y a presque 13 ans
La suppression fonctionne correctement suite aux modifications de Miguel.
J'ai pu notamment vider l'ensemble des éléments de la corbeille sans aucun problème.
Testé avec les données de l'intranoo sur la base de données MS SQL Server 2008.
Mis à jour par Anonyme il y a presque 13 ans
- Assigné à changé de Anonyme à Miguel Moquillon
Mis à jour par Miguel Moquillon il y a presque 13 ans
- Statut changé de In progress... à Resolved
Le code de suppression d'un nœud par l'instanciateur de Node utilise maintenant un code commun avec celui de l'EJB et ce code accepte comme paramètre la connexion à utiliser ; ce qui permet de supprimer un nœud (et ses fils) dans la transaction courante.
Mis à jour par Nicolas Eysseric il y a presque 13 ans
- Statut changé de Resolved à Closed
- % réalisé changé de 0 à 100