Тупики встречаются чаще в двухуровневой архитектуре или в трехуровневой архитектуре? И почему?

Question

Я работаю с Microsoft Navision 2009 и много раз, если, например, сделать новый заказ, и изменить что-то позже на пластинках, то часто происходит, что вы получите сообщение:

Другой пользователь изменил записи и вы не можете ничего сделать до изменить записи.

Итак, теперь мы исследуем, лучше ли перейти на другую версию Navision. Например:

Micrososft Navision 2013. Потому что 2013 используют древовидную архитектуру. И 2009 используют двухуровневую архитектуру.

Так что мой вопрос:

тупики встречаются чаще в архитектуре двухуровневой или в архитектуре трехуровневой? И почему?

Answer 1

Это проблема контроля версий. Возможно, Navision не подходит для ваших нужд. Попробуйте другую систему контроля версий.

Answer 2

Ошибка указывает на что-то, связанное с контролем параллелизма, а не с SQL, как взаимоблокировки (вы начинаете что-то делать с записью, другой пользователь редактирует одну и ту же запись, и вы пытаетесь сохранить свои изменения над модифицированными).

Это не имеет ничего общего с 2 против 3-уровневой архитектуры, но путь concurrency control рассматривается:

• первым, чтобы сохранить изменения побед (оптимистические, редкие конфликты предположение) ИЛИ
• первым войти в режим редактирования блокирует доступ к другим чейнджерами (пессимистический, довольно часто конфликтует предположение)

Подробнее об управлении параллелизмом в Navision можно найти here (пункт 7). Похоже, используется оптимистический контроль параллелизма.

Answer 3

Как @alexei сказал: Это не имеет ничего общего с двухуровневой или трехуровневой архитектурой. И это вовсе не мертвый замок.

Механизм называется оптимистичный замок - что действительно нет блокировка. Программа должна быть разработана с использованием оптимистической блокировки для объектов, которые вряд ли могут быть изменены более чем одним человеком одновременно. Когда 2 человека меняют его в одно и то же время оптимистичная блокировка препятствует тому, чтобы второй человек переписывал первых лиц, не зная об изменении. Так что это хорошо. Он предотвращает конфликты слиянием. Плохо то, что второй человек должен перезагрузить данные, увидеть изменения и снова сделать собственное изменение - или решил не изменять его сейчас.

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

Отсутствие блокировки также является стратегией. Если вы делаете что-то с нуля - без каких-либо фреймворков это по умолчанию. Оба человека могут редактировать объект одновременно, как и при оптимистичной блокировке. Тогда первый сохраняет его. Затем второй сохраняет его и перезаписывает первые изменения без какого-либо знания. Это также может быть стратегией, но в большинстве бизнес-процессов это не очень хорошо.

Это вопрос вашего дизайна приложения, который использует механизм блокировки. Или, если ваше ограничение заключается в использовании одного из них, вы должны создать свое приложение, чтобы оно лучше всего работало с ним.

Answer 4

Как было сказано в других ответах, это не проблема блокировки, это проблема параллелизма. В этом случае обновление до Nav 2013 не будет иметь никакого эффекта. Не говоря уже о том, что Nav 2009 была первой версией для внедрения 3-х уровневых возможностей. Таким образом, вы можете использовать RTC и уровень обслуживания прямо сейчас.

Но опять же, если эта проблема возникла недавно, можно предположить, что вы используете настроенную для вашей версии версию приложения Nav, а не чистый Cronus. В этом случае у вас, вероятно, есть ошибка с чем-то, что часто обновляет ваши заказы, что-то вроде периодической работы для обновления статуса odrer. Работа, подобная этой, может выполняться каждую минуту, и пока пользователю требуется внести изменения в порядок, заказ может обновляться пять раз периодическим заданием. Поэтому ознакомьтесь с вашими изменениями и убедитесь, что это не проблема.

Answer 5

Как уже сказал Алексей и pommes, переход от 2-уровневой к 3-уровневой архитектуре ничего не меняет с точки зрения SQL-блоков/тупиков.

Но, если мы более конкретно говорим о переходе с NAV 2009 на NAV 2013, есть еще несколько изменений, кроме трехуровневой архитектуры, которые были непосредственно сосредоточены на проблеме блокировки SQL.

Одним из них является редизайн продаж и покупка проводки процедур значительно сократить период, когда G/L запись таблица заблокирована: 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

вместе с некоторыми другими особенностями фоне публикации, эти изменения могут привести к СЧА 2013 является более эффективным с точки зрения SQL замках по сравнению с NAV 2009.