Блокировки чаще возникают в двухуровневой или трехуровневой архитектуре? И почему?
Я работаю с Microsoft Navision 2009 и много раз, если, например, вы делаете новый заказ и позже что-то меняете в записях, часто случалось, что вы получите сообщение:
Другой пользователь изменил записи, и вы ничего не можете сделать, чтобы изменить записи.
Итак, теперь мы выясним, лучше ли перейти на другую версию Navision. Например:
Micrososft Navision 2013, Так как 2013 использовать древовидную архитектуру. А также 2009 использовать двухуровневую архитектуру.
Итак, мой вопрос:
Блокировки чаще возникают в двухуровневой или трехуровневой архитектуре? И почему?
5 ответов
Ошибка предполагает что-то, связанное с управлением параллелизмом, а не с SQL, как взаимоблокировки (вы начинаете что-то делать с записью, другой пользователь редактирует эту же запись и пытается сохранить ваши изменения поверх измененных).
Это не имеет ничего общего с 2-х и 3-х уровневой архитектурой, но способ управления параллелизмом имеет место:
- сначала сохранить изменения побед (оптимистично, предположение редких конфликтов) ИЛИ
- первый, чтобы войти в режим редактирования, блокирует доступ для других чейнджеров (пессимистично, довольно часто противоречит предположению)
Подробнее о контроле параллелизма в Navision можно найти здесь (пункт 7). Похоже, используется оптимистичное управление параллелизмом.
Как уже говорили Алексей и Поммес, переход с 2-уровневой на 3-уровневую архитектуру ничего не меняет с точки зрения блоков / тупиков SQL.
Но если мы более конкретно говорим о переходе с NAV 2009 на NAV 2013, есть несколько других изменений, помимо 3-уровневой архитектуры, которые были непосредственно направлены на проблему блокировки SQL.
Одним из них является редизайн процедур размещения продаж и покупок, чтобы значительно сократить период, когда блокируется основная таблица записей: https://blogs.msdn.microsoft.com/nav/2012/10/17/gl-entry-table-locking-redesign-in-microsoft-dynamics-nav-2013/
Другим важным изменением является переключение уровня изоляции, используемого для пессимистического параллелизма (LOCKTABLE и т. Д.), С SERIALIZABLE на REPEATABLE READ. Хотя это можно сделать и для NAV 2009, в NAV 2013 это вариант по умолчанию. Это изменение напрямую уменьшает вероятность блоков / тупиков. Вы можете прочитать больше об этом изменении здесь: https://blogs.msdn.microsoft.com/nav/2011/05/12/microsoft-dynamics-nav-changes-by-version/
Кроме того, весь стек доступа к данным был переписан и весь код, совместимый с native-db, был удален. Это позволило оптимизировать под SQL-сервер (в отличие от нативной архитектуры БД), внедрить более эффективные запросы и кеширование данных. Хотя он не оказывает непосредственного влияния на блоки, это означает более быстрое манипулирование данными и, как следствие, блокировки удерживаются в течение меньшего количества времени. https://msdn.microsoft.com/en-us/library/hh169480(v=nav.70).aspx
Вместе с некоторыми другими функциями фоновой публикации эти изменения могут привести к повышению эффективности NAV 2013 с точки зрения блокировок SQL по сравнению с NAV 2009.
Как было сказано в других ответах, это не проблема блокировки, это проблема параллелизма. В этом случае обновление до Nav 2013 не будет иметь никакого эффекта. Не говоря уже о том, что Nav 2009 был первой версией, которая представила 3-х уровневые возможности. Таким образом, вы можете использовать RTC и сервисный уровень прямо сейчас.
Но с другой стороны, если эта проблема появилась недавно, можно предположить, что вы используете настроенную для ваших нужд версию приложения Nav, а не чистый Cronus. В этом случае у вас, вероятно, есть ошибка с чем-то, что часто обновляет ваши заказы, что-то вроде периодической работы по обновлению статуса odrer. Работа, подобная этой, может выполняться каждую минуту, и, хотя пользователю требуется пять минут, чтобы внести изменения в заказ, заказ может обновляться пять раз с помощью периодической работы. Так что внимательно посмотрите на ваши модификации и убедитесь, что они не проблема.
Как сказал @alexei: Это не имеет ничего общего с двухуровневой или трехуровневой архитектурой. И это не мертвый замок вообще.
Механизм называется оптимистической блокировкой, которая действительно не блокируется. Программа должна быть разработана с использованием оптимистической блокировки для объектов, которые вряд ли могут быть изменены более чем одним человеком одновременно. Когда 2 человека изменяют его одновременно, оптимистическая блокировка не позволяет второму человеку перезаписать первые изменения, не зная об этом. Так что это хорошо. Это предотвращает конфликты слияния. Плохо то, что второй человек должен перезагрузить данные, увидеть изменения и снова должен внести свои изменения - или решает не изменять их сейчас.
Пессимистическая блокировка с другой стороны - это реальная блокировка ресурсов. Человек устанавливает блокировку для объекта, который собирается измениться. Человек меняет сущность и снимает блокировку. Тем временем ни один другой человек не может редактировать заблокированную сущность. Преимущество здесь в том, что второй человек никогда не должен делать работу снова, потому что сохранение никогда не подведет. Но у этого также есть недостатки: второй человек должен ждать. Пользователи забывают разблокировать свои ресурсы, когда они идут на обед или, что еще хуже, когда они идут в отпуск. Таким образом, другие пользователи должны иметь возможность сломать эти блокировки, или программа должна сломать их через некоторое время.
Без блокировки это тоже стратегия. Если вы делаете что-то с нуля - без какой-либо платформы, это по умолчанию. Оба человека могут редактировать объект одновременно, как при оптимистической блокировке. Тогда первый сохраняет это. Затем второй сохраняет его и перезаписывает первые изменения без ведома. Это также может быть стратегией, но в большинстве случаев не очень удачной.
Это вопрос дизайна вашего приложения, какой механизм блокировки использовать. Или, если вы ограничиваете использование одного из них, вы должны спроектировать свое приложение так, чтобы оно работало лучше с ним.
Это проблема контроля версий. Возможно, Navision не подходит для ваших нужд. Попробуйте другую систему контроля версий.