Операторы SELECT SQL Server, вызывающие блокирование
«Очень простой пример прокси-сервера, к которому можно подключиться, а затем он сам попытается подключиться к переданному ему адресу». Это практически определение HTTP-прокси.
Здесь есть действительно простой пример прокси: http://effbot.org/librarybook/simplehttpserver.htm
Суть его всего в 3 строки :
class Proxy(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_GET(self):
self.copyfile(urllib.urlopen(self.path), self.wfile)
Таким образом, это SimpleHTTPRequestHandler, который в ответ на запрос GET открывает URL-адрес в пути (запрос к прокси-серверу обычно выглядит как "GET http: // example .com / ", а не как" GET /index.html "). Затем он просто копирует все, что может прочитать с этого URL, в ответ.
Заметим, что это действительно минимально. Я считаю, что это вообще не касается заголовков.
Кстати: path задокументировано на http://docs.python.org/library/basehttpserver.html . Он был установлен до того, как был вызван ваш метод do*.
5 ответов
SELECT может блокировать обновления. Правильно спроектированная модель данных и запрос вызовут лишь минимальную блокировку и не будут проблемой. «Обычная» подсказка WITH NOLOCK почти всегда является неправильным ответом. Правильный ответ - настроить ваш запрос так, чтобы он не сканировал огромные таблицы.
Если запрос не настраивается, вы должны сначала рассмотреть уровень ИЗОЛЯЦИИ SNAPSHOT , во-вторых, вам следует подумать об использовании DATABASE SNAPSHOTS , а последняя опция должна быть ГРЯЗНЫМ ЧТЕНИЕМ (и лучше изменить уровень изоляции , а не использовать NOLOCK HINT). Обратите внимание, что грязное чтение, как ясно указано в названии, вернет несогласованные данные (например, ваш общий лист может быть несбалансированным).
Общие (S)блокировки позволяют одновременным транзакциям читать(SELECT)ресурс, находящийся под пессимистическим контролем параллелизма . Для получения дополнительной информации см.Типы управления параллелизмом. Никакие другие транзакции не могут изменять данные, пока на ресурсе существуютобщие (S)блокировки.Совместно используемые (S)блокировки для ресурса снимаются, как только операция чтения завершается, если только уровень изоляции транзакции не установлен на повторяющееся чтение или выше, или если используется подсказка блокировки для сохранения общего(S)блокирует на время транзакции.
разделяемая блокировка совместима с другой разделяемой блокировкой или блокировкой обновления, но не с исключительной блокировкой.
Вы можете установить уровень транзакции на Чтение незафиксированных
Также могут возникнуть взаимоблокировки:
«взаимоблокировки с участием только одной таблицы» http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/01/01/reproroduction-deadlocks-involving-only-one-table.aspx
и / или неверные результаты:
"Выбирается в соответствии с READ COMMITTED и REPEATABLE READ может возвращать неверные результаты. "
Для выполнения грязного чтения вы можете либо:
using (new TransactionScope(TransactionScopeOption.Required,
new TransactionOptions {
IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted }))
{
//Your code here
}
, либо
SelectCommand = "SELECT * FROM Table1 WITH (NOLOCK) INNER JOIN Table2 WITH (NOLOCK) ..."
помнить, что вам нужно писать WITH (NOLOCK) после каждой таблицы, которую вы хотите грязное чтение