Sharepoint COMException 0x81020037

Question

Ich arbeite an einer SharePoint-Anwendung, die das Importieren mehrerer Dokumente in einem einzigen Vorgang unterstützt. Ich habe auch einen ItemAdded-Event-Handler, der eine grundlegende Wartung der Item-Metadaten durchführt. Dieses Ereignis wird sowohl für importierte als auch für manuell erstellte Dokumente ausgelöst. Der letzte Teil des Puzzles ist eine Stapelverarbeitungsfunktion, die ich implementiert habe, um einen Workflow zu starten und ein weiteres Metadatenfeld zu aktualisieren.

Ich bin in der Lage, eine COMException 0x81020037 durch Extrahieren der Dateidaten eines SPListItem zu verursachen. Diese Datei ist nur ein InfoPath-Formular/XML-Dokument. Ich bin in der Lage, das XML zu modifizieren und erfolgreich zurück in das SPListItem zu schieben. Wenn ich das benutzerdefinierte Feature sofort danach abfeuern und Metadaten ändern, verursacht es gelegentlich den COM-Fehler.

Die Fehlermeldung zeigt grundsätzlich an, dass die Datei von einem anderen Thread geändert wurde. Es scheint, dass das ItemAdded-Ereignis die Datei weiterhin in die Datenbank schreibt, während die benutzerdefinierte Funktion die Metadaten ändert. Ich habe versucht, Verzögerungen und Fehler auffangende Schleifen einzuführen, um zu versuchen, zu erkennen, dass das SPListItem mit wenig Erfolg sicher zu modifizieren ist.

Gibt es eine Möglichkeit zu sagen, ob ein anderer Thread eine Sperre für ein Dokument hat?

Answer 1

Manchmal sehe ich die ItemAdded oder ItemUpdated feuern zweimal für einen einzigen Vorgang. Sie können versuchen, einen Haltepunkt in der ItemAdded() Methode zu setzen, um dies zu bestätigen.

Die Lösung in meinem Fall war die ItemAdded() Methode einzigen Thread:

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

Ich werde in diesem und Sie suchen müssen, um wieder. Das Problem an meinem Ende scheint zu sein, dass Code in einer anderen Klasse läuft, in einem anderen Feature, das von einem anderen Thread gesteuert wird, von denen alle versuchen, auf denselben Datensatz zuzugreifen.

Ich versuche, eine feste Verzögerung zu vermeiden. Bei jedem Threading-Problem besteht die pathologische Möglichkeit, dass ein Thread das, was wir erwarten, verzögern oder blockieren kann. Bei Bereitstellungen auf unterschiedlicher Serverhardware mit unterschiedlichen Lasten ist dies eine sehr reale Möglichkeit. Am anderen Ende des Spektrums, auch wenn ich mit einer Verzögerung gehen sollte, möchte ich nicht, dass es sehr hoch ist, besonders nicht 30 Sekunden. Mein Kunde wird Zehntausende von Dokumenten importieren, und eine Verzögerung von beträchtlicher Länge wird dazu führen, dass der Import buchstäblich den ganzen Tag dauert.