Всем доброго времени суток!

Нужна консультация.

У нас возникла необходимость обрабатывать большие коллекции Entity(изменять значение поля и обновлять) при этом что бы был задействован событийный слой.

Решили данным способом:

var bc = new BlockingCollection<Entity>();
// Наполнение коллекции
.....
Parallel.ForEach(bc, new ParallelOptions {
   MaxDegreeOfParallelism = Environment.ProcessorCount
}, entity => entity.UpdateInDB(false));

Вопрос в следующем будем ли мы ловить локи при использовании UserConnection entity, не создавая нового?

Подобные случаи с локами были на версии 7.8.


 

Нравится

1 комментарий

Алексей, здравствуйте!

Однозначно ответить на вопрос про блокировки нет возможности, они как могут возникать, так и нет. Но работать с данными в несколько потоков не рекомендуется.

Показать все комментарии

При параллельном сохранении Entity.Save() с использованием параллельных потоков Parallel.ForEach получаю ошибку:

System.Data.SqlClient.SqlException: A trigger returned a resultset and/or was running with SET NOCOUNT OFF while another outstanding result set was active.



Как установить NOCOUNT ON для объекта Entity при сохранении?

Нравится

12 комментариев

Проблема возникает из-за того, что в каком-то триггере в базе данных для таблицы, связанной со схемой Entity не установлен SET NOCOUNT ON.

Для решения проблемы Вам нужно определить, что это за триггер и внести в него изменения.

У меня, например, такая проблема воспроизводилась при попытке удалить бизнес-процесс из конфигураци и возникала для объекта Contact. Для этой таблицы в БД есть триггер завязанный на изменение (UPDATE), но в нем не было установлено SET NOCOUNT ON.

Возможно, что у Вас также проблема именно в этом триггере.

Суть ошибки я понимаю. Вопрос в другом имеем ли мы право вносить правки в системные триггер.

 

Добрый день, Игорь.

Это зависит от того, о каком триггере речь. Генерировался ли он автоматически ядром, или создан специально для этой таблицы разработчиками вручную.

В первом случае менять нежелательно, во втором — нужно будет быть осторожным при установке обновлений, если в пакете будет SQL-запрос обновления стандартного триггера.

Узнать, что это за триггер, можно, наблюдая запросы в профайлере.

Мотков Илья,

Илья, Добрый день.

проблема в базовых триггерах таблиц Contact и Account

Это стандартная логика, связанная с поиском дублей и полем-изображением. Из трёх триггеров на событии вставки и изменения работает только один, обновляющий изображение.

Если дорабатывать или отключать триггер не хотите и сбой наблюдается только после Ваших доработок, есть смысл их переделать на последовательное изменение записей. 

Коновалов Игорь пишет:

Суть ошибки я понимаю. Вопрос в другом имеем ли мы право вносить правки в системные триггер.

Да, исправления нужно внести обязательно, так как это ошибка. Уверенна, что никаких критических проблем не возникнет, однако сначала выполните эти исправления на тестовой базе, протестируйте, а потом переносите на прод.

Если это ошибка, тогда хотелось бы получить от поддержки Terrasoft решение.

Решением будет удаление некорректных сторонних доработок, которые ломают стандартную логику триггеров раздела. В конфигурации вообще использование Parallel.ForEach минимально, только один раз при работе с сервисом рассылок.

Илья, вопрос к триггерам таблицы

- Контрагент:

TRILqybnWrGVlAZ250EZZORaS6GAIU

TRILqybnWrGVlAZ250EZZORaS6GJAD

TRAccountID

- Контакт:

TRContactID

TRILE9Mk5tdkf4ii5Xu52IJW7JlLAD



Все они являются базовыми и все содержат строку

SET NOCOUNT ON

Игорь, это стандартные триггеры. Без крайней необходимости их менять не стоит. Адаптируйте свой код, чтобы он не вызывал сбоев.

Мотков Илья,

Я обрабатываю большой объем данных. Без применения

Parallel.ForEach данная выгрузка займет несколько дней.

Базовые триггеры прерывают данный процесс.



 

Вы можете производить ресурсоемкие манипуляции в отдельной оперативной таблице, а затем в моменты минимальной нагрузки заливать последовательно данные оттуда в основную.

Показать все комментарии