Использование подсказки NOLOCK в EF4?
Мы оцениваем EF4, и мой DBA говорит, что мы должны использовать подсказку NOLOCK во всех наших операторах SELECT. Таким образом, я изучаю, как заставить это произойти при использовании EF4.
Я считал различные идеи о том, как заставить это произойти в EF4, но все походят на работу вокруг и не санкционированные Microsoft или EF4. Какова "официальная Microsoft" ответ кому-то, кто хочет, чтобы их оператор (операторы) SELECT включал подсказку NOLOCK при использовании LINQ-SQL / LINQ к объектам и EF4?
Между прочим, абсолютная лучшая информация, которую я нашел, была прямо здесь, и я поощряю всех заинтересованные этой темой читать этот поток.
Спасибо.
3 ответа
NOLOCK = "READ Unmized" = грязные чтения
Я бы предположил, что MS знает, почему они выбрали уровень изоляции по умолчанию как «чтение преданно»
Nolock, на самом деле любой подсказку, следует использовать очень разумно: не по умолчанию.
Ваша DBA - это маппет. Смотрите это (так): Что может произойти в результате использования (Nolock) на каждом выборе в SQL Sever? . Если вы служите на работе в банке или любом учреждении, где у меня может быть аккаунт, пожалуйста, дайте мне знать, чтобы я мог закрыть его.
Я знаю, что это не ответ на ваш вопрос, но я просто хотел бросить это.
Мне кажется, что это (по крайней мере частично) работой ДБА. Это нормально сказать, что приложение должно вести себя определенным образом, и вы можете и, безусловно, пытаетесь попробовать его так, как он хотел бы.
Единственный способ быть уверенным, что DBA работает над приложением с вами и построить поверхность БД, которую он хотел бы представить в приложении. Если он хочет, чтобы критические таблицы были запрошены в качестве прочтения незарегистрированного, то он должен помочь обеспечить набор хранимых процедур с правильным уровнем доступа и изоляции.
Опираясь на код приложения для построения каждого специального запроса правильно, не является масштабируемым подходом.
Я разработчик в группе инструментов в организации SQL в Microsoft. Я никоим образом не уполномочен делать какие-либо официальные заявления, и я уверен, что на SO есть люди, которые знают об этих вещах больше, чем я. Тем не менее, я предлагаю дружеское практическое правило по теме «Преждевременная оптимизация - корень всех зол»:
Не используйте NOLOCK (или любые другие подсказки в этом отношении), пока вам не придется . Если у вас есть оператор select, который имеет приличный план запроса, и он отлично работает, когда на систему очень мало другой нагрузки, но затем он замедляется, когда другие запросы обращаются к той же таблице, попробуйте добавить некоторые подсказки NOLOCK. Но всегда помните, что когда вы это сделаете, вы рискуете получить противоречивые данные. Если вы пишете какое-то критически важное приложение, которое выполняет онлайн-банкинг или управляет самолетом, это может быть неприемлемо. Однако для многих приложений ускорение производительности стоит риска.Однако оценивайте в индивидуальном порядке. Не используйте их волей-неволей повсюду.
Если вы решите использовать NOLOCK, я опубликовал в блоге решение на C # с использованием методов расширения, так что вы можете легко изменить запрос LINQ для использования подсказок NOLOCK. Если вы можете адаптировать это к EF4, опубликуйте свою адаптацию.