Sharepoint COMException 0x81020037

Question

Je travaille sur une application SharePoint qui prend en charge l'importation de plusieurs documents en une seule opération. J'ai également un gestionnaire d'événement ItemAdded qui effectue une maintenance de base des métadonnées de l'élément. Cet événement se déclenche à la fois pour les documents importés et ceux créés manuellement. La dernière pièce du puzzle est une fonctionnalité de traitement par lots que j'ai implémentée pour lancer un flux de travail et mettre à jour un autre champ de métadonnées.

Je suis capable de provoquer une exception COMException 0x81020037 en extrayant les données de fichier d'un SPListItem. Ce fichier est juste un formulaire InfoPath/document XML. Je suis capable de modifier le XML et de le repousser avec succès dans le SPListItem. Lorsque je déclenche la fonction personnalisée immédiatement après et modifiez les métadonnées, il provoque occasionnellement l'erreur COM.

Le message d'erreur indique essentiellement que le fichier a été modifié par un autre thread. Il semblerait que l'événement ItemAdded écrit toujours le fichier dans la base de données pendant que la fonction personnalisée modifie les métadonnées. J'ai essayé de mettre en retard et de rattraper les boucles d'erreur pour essayer de détecter que le SPListItem est sûr de modifier avec peu de succès.

Y at-il un moyen de savoir si un autre thread a un verrou sur un document?

Answer 1

Parfois, je vois le ItemAdded ou ItemUpdated tirant deux fois pour une seule opération. Vous pouvez essayer de mettre un point d'arrêt dans la méthode ItemAdded() pour le confirmer.

La solution dans mon cas était à seul thread la méthode ItemAdded():

private static object myLock = new object(); 
public override void ItemAdded(SPItemEventProperties properties) { 
    if (System.Threading.Monitor.TryEnter(myLock, TimeSpan.FromSeconds(30)) 
    { 
     //do your stuff here. 
     System.Threading.Monitor.Exit(myLock); 
    } 
} 

Answer 2

Je vais devoir examiner cela et revenir à vous. Le problème de mon côté semble être que le code s'exécute dans une classe différente, dans une fonctionnalité différente, étant contrôlé par un thread différent, tous essayant d'accéder au même enregistrement. J'essaie d'éviter d'utiliser un délai fixe. Avec n'importe quel problème de threading, il y a la possibilité pathologique qu'un thread puisse retarder ou bloquer au-delà de ce que nous attendons. Avec des déploiements sur différents matériels serveur avec des charges différentes, c'est une possibilité très réelle. À l'autre bout du spectre, même si je devais partir avec un retard, je ne veux pas qu'il soit très élevé, surtout pas 30 secondes. Mon client va importer des dizaines de milliers de documents, et un retard de n'importe quelle longueur importante provoquera littéralement l'importation toute la journée.