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

[fed]

Цитата:

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

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

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