И вновь уроки про deadlock-и

Значимый прорыв формирует отрасль ИИ: imschur 9 минут назад И вновь уроки про deadlock-и Средний 7 мин 252 SQL * PostgreSQL * Базы данных * Многие из backend-разработчиков получали ошибки с неприятным содержанием, суть которого можно описать двумя словами: deadlock detected. Возникают они там, где их не ждёшь, отладочной информации крайне мало или вообще нет, и для их решения необходимо глубокое понимание архитектуры как самого запроса и метода, из которого он вызвался (или методов, возможно, чужих... ), так и архитектуры самой СУБД.

Поэтому часто у таких ошибок либо переносится срок, либо попытки их исправить приводят к тому, что они возвращаются снова и снова. А deadlock-и так никуда и не исчезают. Прежде чем говорить о взаимоблокировках отметим, что любое изменение записи — добавление, редактирование и удаление — 1) происходит внутри конкретной транзакции и 2) всегда накладывает на запись блокировку.

Технические детали

Для упрощения я не буду здесь рассматривать частичные блокировки — это не сильно влияет на понимание сути проблемы. Просто условимся, что всегда блокируется запись целиком. При этом прочитать запись можно (СУБД-блокировочники в расчёт не берём), и прочитана будет та версия записи, которая доступна текущей транзакции на основании её уровня изоляции и состояния БД в момент её старта.

При этом транзакция, которая изменила запись, конечно же увидит свои изменения. Но если другие транзакции попытаются что-либо сделать с этой же записью — отредактировать, удалить или добавить такую же (при наличии уникального индекса), они встанут на наложенную другой транзакцией блокировку и будут ждать, пока изменившая запись транзакция не завершится. Взаимоблокировка, или deadlock, — это состояние, когда из-за наложившихся друг на друга блокировок дождаться завершения какой-либо из транзакций, удерживающих запись, становится невозможно.

К счастью, все СУБД умеют отслеживать взаимоблокировки и принудительно завершать блокирующие транзакции по истечении определённого лимита времени. Это для них как фундамент, основа, без которой СУБД не может существовать. Но наличие подобного механизма не означает, что разработчику ничего не нужно делать с взаимоблокировками — напротив, важно найти причину взаимоблокировки и её устранить.

Отраслевые последствия

В этой статье я постарался собрать известные сценарии взаимоблокировок, встречающиеся в повседневной практике и рассмотрел их на примере СУБД PostgreSQL. Также отдельно рассмотрен особый вид взаимоблокировок — взаимоблокировки на уровне приложения, с которыми СУБД самостоятельно справиться не может в принципе. Классическая взаимоблокировкаСценарий классической взаимоблокировки следующий:Стартуют две транзакции — 1 и 2.

Транзакция 1 меняет запись А. Транзакция 2 меняет запись Б. Транзакция 1 пытается изменить запись Б и встаёт на блокировку, ожидая завершения транзакции 2.

Транзакция 2 пытается изменять запись А и встаёт на блокировку, ожидая завершения транзакции 1.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.