Цитата:
Сообщение от
Recoilme
но ведь если все в одной транзакции то какую роль может играть порядок сортировки?
тормозят запросы - их надо оптимизировать, думать не надо )
Ну я же написал в самом начале. :-(
Работа с разными строчками идет в одной транзакции, а заказы - в разных обрабатываются с разных рабочих мест, но одновременно
Ну смотрите :
заказ 1
Строка 1 Номенклатура1
Строка 2 Номенклатура2
заказ 2
Строка 1 Номенклатура2
Строка 2 Номенклатура1
С одного рабочего места начинается транзакция, которая перебирает строки заказа1
обновила строку с номенклатурой1 и на соответсвующей InventSum повесила блокировку, так что другая транзакция не сможет получить её forUpdate ( на чтение прочитает, а forUpdate - фиг)
В это же время с другого рабочего места начинается другая транзакция которая обрабатывает заказ 2 обработала в нем строчку номер 1 в которой находится номенклатура 2 и в резульате по номенклатуре 2 повесила блокировку на InventSum, так что никакая другая транзакция не может получить её ForUpdate
А дальше первая транзакция пытается получить forUpdate InventSum с номенклатурой 2 - но не может и ждет завершения второй транзакции.
а вторая транзакция хочет отобрать forUpdate InventSum с номенклатурой 1 но не может, потому что на ней висит блокировка от первой транзакции. И поэтому вторая транзакция тоже ждет.
Вот так они друг друга ждут - классический DeadLock.
Он может длиться сколь угодно долго пока БД по таймауту не откатит одну из транзакций.
Эта фигня может возникать на сколь угодно можных серверах и сколь угодно оптимизированных запросах. Все дело в порядке перебора записей разными транзакциями.
А если мы будем перебирать строки заказа по ItemId то как не трудно заметить мертвой блокировки не получится.
Просто одна из транзакций успеет раньше заблокировать Номенклатуру 1 а другая транзакция подождет заверешения её работы вот и все.