Мертвые блокировки при резерве
Добрый день, всем.
Разбирал недавно код Аксапты - однако много думал :-(
Кратко :
Есть проблема - возникают мертвые блокировки при резервировании по заказу. В системе создана функция которая в одной транзакции резервирует все строки по заказу. (Функция стартует по кнопке. При работе просто перебирает строчки и для каждой делает резерв. Порядок строк оставлен на усмотрение движка базы данных)
Мертвые блокировки возникли на таблице InventSum.
Первая догадка - мертвые блокировки возникают потому что при резервировании разных заказов номенклатуры в них перебираются в разном порядке. Например в одном Номенклатура1 затем Номенклатура2 а в это же время в другом заказе в обратном порядке Номенклатура2 затем Номенклатура1 - потенциально это с большой вероятностью приводит к мертвой блокировке в системе.
Чтобы этого избежать правильнее было бы везде при переборе строк заказа ставить сортировку по ItemId а также в классах ответственных за резервирование стараться чтобы аналитики перебирались в одном порядке.
Теперь, внимание! Самое интересное то, что в таблице SalesLine нет индекса в который бы входили поля SalesId, ItemId (и который был бы полезен для этих целей) Вместо него есть индекс SalesId, LineNum. Кроме того семейство классов SalesFormLetter и SalesTotals используют при переборе строк Query в котором сорировка стоит по LineNum.
Например, в SalesFormLetter.updateQueryBuild()
стоит
chooseLines.query().dataSourceTable(tableNum(SalesLine)).addSortField(fieldNum(SalesLine, salesId));
chooseLines.query().dataSourceTable(tableNum(SalesLine)).addSortField(fieldNum(SalesLine, lineNum));
Таким образом проблема блокировок может возникнуть даже при простой обработке заказа. ( Нам видимо до сих пор везло)
Вот я сижу и думаю, почему разработчики аксапты поставили везде сортировки по LineNum.
Может какая-то идея хитрая была. Мне вот кажется что для целей производительности лучше везде ставить сортировку по ItemId. Ну и еще для верности по аналитике.
Последний раз редактировалось Logger; 17.05.2006 в 13:02.
|