Sharepoint COMException 0x81020037

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

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

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

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


multithreading sharepoint com
person Jason Z    schedule 22.08.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Иногда я вижу, как 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);
    }
}
person vitule    schedule 22.08.2008

arrow_upward
0
arrow_downward

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

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

person Jason Z    schedule 22.08.2008