DynamicsAxSCM: Back ported features from Dynamics AX 2012 to Dynamics AX 2009

[Logger]

Цитата:

Сообщение от fed

Версионник уже давно сделали. Но блокировки все равно нужны для:
1. Предотвращения конфликтов записи
2. Ситуаций, грубо говоря, продажи билетов на поезд. Когда надо обеспечить чтобы между чтением ресурса и его обновлением он был заблокирован и недоступен для обновления другими сессиями.

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

Цитата:

Сообщение от fed

Кроме того, сами по себе эскалация блокировок - не такое уж зло. Если у тебя таблица построчных блокировок разростается в памяти, то каждая новая операция обновления занимает все больше времени, поскольку надо все больше и больше времени искать в таблице блокировок ID текущего объекта. И во многих случаях, эскалация на самом деле повышает производительность работы с БД. Идеальным вариантом, на мой взгляд, была бы возможность отключать эскалацию каким-то хинтом в конкретном запросе, а главное - интерфейс к этому хинту из X++.

Ключевое слово - "памяти". Денис, ты неявно предполагаешь какую то конкретную реализацию механизма блокировок (как я понимаю майкрософтовскую) и говоришь о её недостатках. Если не ошибаюсь оракл хранит инфу о блокировках на диске в самих записях, так что при большом числе блокировок памяти дополнительной не тратится. Работает достаточно шустро.

Наверно есть и другие способы реализации механизма блокировок, экономно расходующие память и прочие ресурсы БД. Обсуждение куда-то в сторону уходит.

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