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

invm,

Забавный Вы тролль :)

Сначала кривляетесь, по сути, утверждая, что никаких дидлоков не будет.
invmptr128Он собирался обновлять несколько записей одной таблицы в произвольном порядке в пределах одной транзакции, что гарантированно будет приводить к дидлокам.
Теперь ТС испугается страшного слова и будет в цикле обновлять каждую строку в отдельной транзакции.

Потом занимаетесь демагогией, приплетя вдруг триггеры:
invm Сначала вы доказывайте свою правоту насчет неприменимости триггеров.
Совершенно проигнорировав то, что триггеры употреблялись в совсем другой фразе:
ptr128правильные подходы, с двух шаговой обработкой (резервирование по всем строкам, если успешно - то списание), но они далеко выходят за рамки задачи, поставленной ТС и уж точно не предназначены для реализации в триггере.
Которая говорит только о том,
ptr128что триггер по определению выполняется внутри транзакции.
Следовательно, пытаться разбить одну большую транзакцию на мелкие, в триггере просто бессмысленно.

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

При этом Вы еще не понимаете, как можно извиняться за откровенное хамство
invmТеперь ТС испугается страшного слова...
У вас классный хрустальный шар...
Очередной триггерофоб...
пишите фигню...

TaPaKа тема то интересная :)
автор Он собирался обновлять несколько записей одной таблицы в произвольном порядке в пределах одной транзакции, что гарантированно будет приводить к дидлокам.

это как же...

Чукча не читатель, чукча писатель? 21061621

JaffarВСе это чушь.
Ну Вы достаточно ёмко и самокритично озаглавили свой пост.
Но я все же разберу его

JaffarЕсть историческая таблица с остатками типа:
(IDTowar, Date, Count, SUM)

и таблица с документами типа
IDDOC
TypeDoc,
DTDOC
DeltaCount,
Price
Sum,
и т.п.

Документы меняют состояние исторической таблицы с остатками - все остальное ерунда.
Во-первых, начнем с того, что есть не таблица с документами, а, как минимум, две таблицы - заголовок документа и его строки.
Во-вторых, просто обновить агрегированные количества одним запросом нельзя, так попытка
ptr128обновлять несколько записей одной таблицы в произвольном порядке в пределах одной транзакции, [...] гарантированно будет приводить к дидлокам
Что доказано тут 21061621

ptr128более правильные подходы, с двух шаговой обработкой (резервирование по всем строкам, если успешно - то списание)
подразумевают, следующий механизм.
1. В каждой строке документа у нас есть флаг, который мы выставляем в 1 в случае успешного резервирования. В заголовке документа имеем так же флаг проведения всего документа или, что чаще встречается, факт проведения отражается совсем в другой таблице.
2. В таблице агрегатов имеем не только актуальный остаток, но еще и зарезервированное количество. Доступное количество рассчитывается как их разность.
3. По каждой строке документа отдельной транзакцией выполняется резервирование (увеличение зарезервированного количества) с проверкой того, хватает ли для этого доступного количества. В той же транзакции в строке устанавливается флаг резервирования.
4. Если резервирование всех строк прошло успешно, то есть доступного количества хватило для всех позиций в документе, мы опять, по каждой строке документа отдельной транзакцией выполняем уменьшение актуального количества, зарезервированного количества и сбрасываем флаг резервирования в строке.
5. Если резервирование хотя бы для одной строки не удалось, то мы снова, по каждой строке документа, в которой установлен флаг резервирования, отдельной транзакцией, уменьшаем зарезервированное количество и сбрасываем флаг резервирования.
6. Механизм логической транзакции и средства восстановления после сбоя я тут опускаю, хотя их реализация обязательна.

invmМожет рассекретите цепочку рассуждений, которая к нему приводит?
Задайте конкретный вопрос - получите конкретный ответ. А мне Ваша логика совершенно непонятна и Вы ее нигде еще не озвучили.

invmА утверждение о неприменимости триггеров так и осталось без объяснений...
Ну я думал, что Вы хоть немного в теме. Впрочем это явно выходит за рамки простых задач, как у ТС, потому будем считать для Вас простительным.
1. Обновление нескольких записей одной таблицы в произвольном порядке в пределах одной транзакции гарантировано приводит к дидлоку. Вопрос только в количестве записей, количестве пользователей и во времени, когда это произойдет.
2. Обновлять записи в таблице всегда в одном порядке не позволяет сам синтаксис UPDATE.
3. Блокировать всю таблицу, в которой обновляются записи, не применимо с точки зрения производительности системы.
4. Остается только единственный путь - разбить одну транзакцию на множество мелких, что не возможно сделать внутри триггера, так как любой триггер всегда выполняется уже внутри транзакции.
Вывод: если для избежания дидлоков одну большую транзакцию необходимо разбить на несколько мелких, то в триггере это сделать не возможно.


invmptr128А так как актуальные остатки используются только для отчета , то тут я бы, скоре, READ UNCOMMITED использовал )Даже страшно представить к чему это приведет...
И к чему? К тому что пользователь, построивший отчет в тот момент, когда выполняется постинг увидит, что часть количеств уже списалась, а часть нет? И на что это повлияет? А что было бы, если бы пользователь построил отчет на секунду раньше, еще до начала постинга? Или на секунду позже, после завершения постинга?
У Вас страхи совершенно детские и абстрактные. Вам Ваши способности даже не позволяют их конкретизировать )))

invmЗаодно найдете в одном из них порожденную вами же связь между триггером и дедлоком.
Пожалуйста, не лгите так нагло. Или скриншот сюда.

invmИ все это вместо отлова ошибки 1205 и организации повтора транзакции...
Именно так. Потому что, по умолчанию, на SQL сервере транзакции в дидлоке сидят до 5(!) секунд.
Так как при этом данные транзакции могут блокировать еще ряд других процессов, то такой подход может приводить к зависаниям на эти 5 секунд вообще всей системы. Я даже не знаю области применения такого решения, чтобы заказчик не вытряс душу из техподдержки.

invmА возникновение при этом дедлока - побочный эффект, обработку которого грамотный роазработчик обязан предусмотреть. Но, похоже, что "грамотный" - это не про вас.
Предложите свое "грамотное" решение. Или только флудить в состоянии?

invmСостав транзакции определяется бизнес-требованиями
Давно так не ржал. Еще и коллег повеселил )))
Бизнес-требование, если это, конечно, не заказной тендер, не то что состав транзакции не ограничивает, а даже платформу и программный продукт. Клиенту важен результат, а как его разработчик добился - его интересует исключительно только с той точки зрения, за сколько часов разработчика ему акт выставили.