Наш администратор базы данных пришел к нам с информацией о том, что наши запросы LINQ создают тысячи блокировок в базе данных.Разработчик из нашей команды выкопал этот пост Гансельмана в качестве возможного решения нашей проблемы:
http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx
Скотт предлагает 3 способа LINQ для настройки NOLOCK.1) TransactionScope (предпочтительно), 2) SPROCS, 3) context.ExecuteCommand
Мы новостной сайт, который читает 99%, пишет 1%, поэтому мы уделяем основное внимание скорости поиска.Является ли NOLOCK хорошей стратегией для всех наших запросов LINQ-TO-SQL?
Я пытаюсь понять, что почему использование NOLOCK является или не являетсяотличная идея.У нас должно быть много людей с теми же целями: много быстрого чтения, мало обновлений.Если NOLOCK - очевидный ответ, то почему он не используется по умолчанию?Почему я не могу установить его по умолчанию для контекста, вместо того, чтобы устанавливать его при каждом вызове данных?
Действительно ли NOLOCK - лучший вариант для сайта быстрого чтения и нескольких обновлений?
ОБНОВЛЕНИЕ: В SQL Server 2005 и более поздних версиях изоляция моментального снимка лучше, чем NOLOCK? Я только что обнаружил это http://msdn.microsoft.com/en-us/library/ms179599.aspx
, которое охватывает READ COMMITTED SNAPSHOT .Это предотвращает блокировку записи, но не возвращает грязные данные?Должно ли это использоваться 90% времени по сравнению с NOLOCK?
ОБНОВЛЕНИЕ 2: Что меня беспокоит, так это СУХОЙ
Больше всего меня беспокоит то, что для реализацииили шаблон без блокировки или моментальный снимок, я должен изменить его для КАЖДОГО метода запроса LINQ-to-SQL (кроме тех, которые используются в обновлениях).Это пахнет как серьезное нарушение СУХОГО.