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

[Logger]

Цитата:

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

...
Наши ПМы рассуждают так:
...

Хм. Но ведь для 2012-й проблемы блокировок нет, сделали все так как и fed предлагал.
Уж так и бы и сказали что не хотят ничего менять в 2009-й

P.S.
Вопрос наверно для другой ветки, но неужели MS до сих пор не может решить проблему эскалации блокировок ? Неужели нельзя сделать настоящий версионник, а-ля Оракл, Postgre, FireBird и не мучаться ? Мы сейчас живем на оракл - вообще не знаем таких слов "эскалация". Очень радует

[fed]

Цитата:

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

Вопрос наверно для другой ветки, но неужели MS до сих пор не может решить проблему эскалации блокировок ? Неужели нельзя сделать настоящий версионник, а-ля Оракл, Postgre, FireBird и не мучаться ?

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

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

[Logger]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[Evgeniy2020]

а OCC выключен для этих таблиц? или в данной задаче OCC не поможет?
или там принудительно включен PCC?

[fed]

Цитата:

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

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

Я когда-то на информиксе начинал. Там таблица блокировок в памяти хранилась, при этом размер таблицы блокировок был фиксированным и задавался в конфигурационном файле. Если ты пытался обновить больше строк чем было свободного места в таблице блокировок, то твой update, без объявления войны, завершался с кодом ошибки. Там мне как раз эскалации не хватало, поскольку при загрузке справочников приходилось их резать на порции по 10000 записей. (Возможно в свежих версиях информикса это дело поправили, но я давно им не занимаюсь).
В оракле информация о блокировках храниться в заголовке блока. Подробности про это рассказаны в http://my-oracle.it-blogs.com.ua/post-239.aspx. Тоже, на самом деле, не идеальный вариант. Во первых - часть полезного пространства блока отъедается под данные о блокировках, во вторых - если ты с числом слотов под данные о блокировках не угадал при создании таблицы, то транзакции точно также блокируются в ожидании места под запись о блокировке, даже если никаких объективных конфликтов блокирования нету... Ну то есть - оба подхода имеют свои плюсы и минусы, в каких-то случаях оракловский подход лучше работает, в каких-то микрософтовский. Хочешь работу без эскалации, будь готов получить какие-то другие грабли взамен...

[Logger]

Цитата:

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

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

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

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

[Maxim Gorbunov]

Пожалуй, оставлю здесь ссылку на свою связанную тему:

Нефинансовые перемещения не раскрываются при отмене закрытия