Sharepoint COMException 0x81020037

Question

Я работаю над приложением SharePoint, которое поддерживает импорт нескольких документов за одну операцию. У меня также есть обработчик события ItemAdded, который выполняет базовое обслуживание метаданных элемента. Это событие запускается как для импортированных документов, так и для созданных вручную. Последний фрагмент головоломки - это функция пакетной операции, которую я реализовал, чтобы запустить рабочий процесс и обновить другое поле метаданных.

Я могу вызвать COMException 0x81020037, извлекая данные файла SPListItem. Этот файл является просто формой InfoPath / XML-документом. Я могу изменить XML и успешно перенести его обратно в SPListItem. Когда я сразу же запускаю пользовательскую функцию и изменяю метаданные, это иногда вызывает ошибку COM.

Сообщение об ошибке в основном указывает на то, что файл был изменен другим потоком. Казалось бы, событие ItemAdded все еще записывает файл обратно в базу данных, в то время как пользовательская функция меняет метаданные. Я попытался вставить задержки и циклы перехвата ошибок, чтобы определить, что SPListItem безопасен для изменения с небольшим успехом.

Есть ли способ определить, заблокирован ли другой поток документа?

Answer 1

Иногда я вижу стрельбу ItemAdded или 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);
    }
}

Answer 2

Мне придется разобраться в этом и вернуться к вам. Проблема с моей стороны, кажется, в том, что есть код, выполняющийся в другом классе, в другой функции, управляемый другим потоком, каждый из которых пытается получить доступ к одной и той же записи.

Я стараюсь избегать использования фиксированной задержки. При любой проблеме с потоками существует патологическая вероятность того, что один поток может задержать или заблокировать то, что мы ожидаем. При развертывании на другом серверном оборудовании с разными нагрузками это вполне реальная возможность. На другом конце спектра, даже если бы мне пришлось идти с задержкой, я не хочу, чтобы она была очень высокой, особенно не 30 секунд. Мой клиент будет импортировать десятки тысяч документов, и задержка любой значительной длины приведет к тому, что импорт займет буквально весь день.