Сериализуемый уровень изоляции атомарности - PullRequest
2 голосов
/ 16 февраля 2011

У меня есть несколько потоков, выполняющих некоторые запросы выбора SQL с сериализуемым уровнем изоляции. Я не уверен, какую реализацию выбрать. Это:

_repository.Select(...)

или это

lock (_lockObject)
{
   _repository.Select(...);
}

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

P. S. Я использую MySQL, но думаю, это более общий вопрос.

1 Ответ

3 голосов
/ 16 февраля 2011

Транзакции, выполняющие запросы SELECT, устанавливают общую блокировку на строки , позволяя другим транзакциям читать эти строки, но не позволяя им вносить изменения в строки (включая вставку новых записей в промежутки)

Блокировка в приложении делает что-то другое, это не позволит другим потокам ввести кодовый блок , который выбирает данные из хранилища. Такой подход может привести к очень плохой производительности по нескольким причинам:

  1. Если какая-либо строка заблокирована другой транзакцией (вне приложения) через монопольную блокировку, блокировка в приложении не поможет.
  2. Несколько транзакций не смогут выполнять чтение даже для строк, которые не заблокированы в монопольном режиме (не обновляются).
  3. Блокировка не будет снята, пока все данные не будут получены и возвращены клиенту. Это включает задержку в сети и любые другие издержки, необходимые для преобразования результирующего набора MySql в объект кода.
  4. Самое главное, обеспечение целостности и атомарности данных - это работа с базами данных, она знает, как с ней хорошо справляться, как обнаруживать потенциальные тупики. Когда выполнять блокировки записи, а когда добавлять индексные блокировки. Это то, для чего нужны базы данных, и MySql является жалобой ACID и доказано, что справляется с этими ситуациями

Я предлагаю вам прочитать Раздел 13.2.8. Модель транзакций InnoDB и блокировка документации MySql, она даст вам отличное представление о том, как выполняется блокировка в InnoDB.

...