1

1 回の操作で複数のドキュメントのインポートをサポートする SharePoint アプリケーションに取り組んでいます。また、アイテム メタデータの基本的なメンテナンスを実行する ItemAdded イベント ハンドラーもあります。このイベントは、インポートされたドキュメントと手動で作成されたドキュメントの両方に対して発生します。パズルの最後のピースは、ワークフローを開始して別のメタデータ フィールドを更新するために実装したバッチ操作機能です。

SPListItem のファイル データを抽出することで、COMException 0x81020037 を発生させることができます。このファイルは単なる InfoPath フォーム/XML ドキュメントです。XML を変更して、SPListItem に正常にプッシュすることができました。その直後にカスタム機能を起動してメタデータを変更すると、時折 COM エラーが発生します。

エラーメッセージは基本的に、ファイルが別のスレッドによって変更されたことを示しています。カスタム機能がメタデータを変更している間、ItemAdded イベントはまだファイルをデータベースに書き戻しているようです。SPListItem が安全に変更できることを検出するために、遅延とエラー キャッチ ループを挿入しようとしましたが、ほとんど成功しませんでした。

別のスレッドがドキュメントをロックしているかどうかを確認する方法はありますか?

4

2 に答える 2

1

1回の操作でItemAddedorが 2 回起動することがあります。ItemUpdatedメソッドにブレークポイントを設定して、ItemAdded()それを確認できます。

私の場合の解決策は、メソッドをシングルスレッドにすることでした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);
    }
}
于 2008-08-22T15:48:33.197 に答える
0

I'll have to look into that and get back to you. The problem on my end seems to be that there is code running in a different class, in a different feature, being controlled by a different thread, all of which are trying to access the same record.

I am trying to avoid using a fixed delay. With any threading issue, there is the pathological possibility that one thread can delay or block beyond what we expect. With deployments on different server hardware with different loads, this is a very real possibility. On the other end of the spectrum, even if I were to go with a delay, I don't want it to be very high, especially not 30 seconds. My client will be importing tens of thousands of documents, and a delay of any significant length will cause the import to take literally all day.

于 2008-08-22T16:25:21.967 に答える