Правильно ли я понимаю работу с блокировками строк?

Question

[X110111]

Добрый день.
Если я правильно всё понимаю, блокировки нам нужны для обеспечения корректного поведения при конкурентном доступе.
Типичный пример - работа с балансом пользователя.
Если услуга стоит 20, а у пользователя на балансе 30, то теоретически возможна ситуация, когда две конкурирующие транзакции считывают значение 30, приложение видит что всё ок и дважды предоставляет услугу, хотя денег хватает только на одно списание.
Именно для этого и нужно использовать блокировку.

• 
  Начинаем транзакцию.
  
  
• 
  Производим блокировку.
  

  SELECT balance FROM users WHERE id = 1 LIMIT 1 FOR UPDATE;

  
  
  
• 
  В приложении проверяем что денег достаточно и производим списание.
  

  UPDATE users SET balance = balance - 20 WHERE id = 1;

  
  
  
• 
  Фиксируем транзакцию.
  
  

Верно?

А вот если нам не нужно делать никаких предварительных проверок, то и блокировка нам тоже не нужна?
Например, если мы делаем какой-нибудь счётчик просмотров. В этом случае нам достаточно будет выполнить

UPDATE articles SET views = views + 1 WHERE id = 1;

И в этом случае всё и так будет корректно работать и никаких "потерянных" значений у нас не будет?

Если последнее утверждение верно, то в случае перевода с баланса одного пользователя на баланс другого пользователя, мы должны заблокировать того, с кого списываем, но того, кому зачисляем, блокировать не нужно?
Грубо говоря, мы должны получить примерно следующее?

• 
  Старт транзакции.
  
  
• 
  Чтение с блокировкой.
  

  SELECT balance FROM users WHERE id = 1 LIMIT 1 FOR UPDATE;

  
  
  
• 
  Проверяем что баланс достаточен.
  
  
• 
  Производим списание.
  

  UPDATE users SET balance = balance - 50 WHERE id = 1;

  
  
  
• 
  Производим зачисление.
  

  UPDATE users SET balance = balance + 50 WHERE id = 2;

  
  
  
• 
  Фиксируем транзакцию.
  
  

Верно ли я всё понимаю, или какие есть ошибки?

Answer 1

[Алексей Уколов]

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

UPDATE articles SET views = views + 1 WHERE id = 1;

Но иногда про это забывают и делают не поле + 1, а полученное-ранее-значение-поля + 1. И тогда при конкурентном доступе счётчик начинает работать неправильно и нужно использовать блокировку (а лучше - нормальный запрос выше, который её не требует).

Comments

[X110111]

Спасибо за ответ.

Но иногда про это забывают и делают не поле + 1, а полученное-ранее-значение-поля + 1.

Я специально написал правильный вариант, поскольку очевидно, что в первом случае блокировка необходима. Между операциями select и update может многое произойти и ранее полученное значение будет уже неактуальным.
Больше интересовало то, верно ли я рассуждаю, что в случае правильного варианта дополнительных телодвижений не требуется и явная блокировка будет лишней.

Может быть ответите мне ещё на один вопрос, или подтолкнёте в нужном направлении. Был бы благодарен.

А можем ли мы каким-либо образом предотвратить создание непреднамеренных дублей, без использования уникальности?

Вот у меня была ситуация, я заказывал такси и запрос был отправлен, но лагнул интернет и ответ не пришёл. А когда я нажал на "заказать" ещё раз, увидел что-то вроде: возможно вы случайно делаете повторный заказ, хотите ли заказать ещё одну машину?
Но между этими событиями прошло некоторое время.
А вот если бы ситуация развивалась в условиях гонки транзакций:

• 
  Первая транзакция выполняет чтение и видит что такого заказа ещё нет.
  
  
• 
  Вторая транзакция выполняет чтение и видит что такого заказа ещё нет.
  
  
• 
  Первая транзакция выполняет запись, создавая заказ.
  
  
• 
  Вторая транзакция выполняет запись, создавая заказ. Она же не знает, что он уже создан.
  
  

Как я понимаю, в этом случае создаются дубли и предотвратить это не возможно?
И уникальность тут тоже ведь не подходит. Да, мы можем собрать все параметры заказа (идентификатор клиента + пункт отправления + пункт назначения + тип оплаты + тип авто + время подачи авто), на основе этого вычислить хеш, но делать этот столбец уникальным нельзя. Я же могу вполне сделать два идентичных заказа. Вдруг у меня семья большая?

Answer 2

[Константин Цветков]

С картинками
Явная транзакция:

НАЧАТЬ
ИЗМЕНИТЬ баланс
ЕСЛИ баланс < 0
  ТО ОТКАТИТЬ
  ИНАЧЕ ЗАВЕРШИТЬ

Неявная транзакция (запускается для каждой операции INSERT, UPDATE или DELETE). Делаете для таблицы ОГРАНИЧЕНИЕ баланс >= 0. И в неявной транзакции ИЗМЕНИТЬ будет ОТКАТИТЬ при балансе < 0.

Comments

[X110111]

Спасибо.

Answer 3

[nApoBo3]

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

Comments

[X110111]

Спасибо за ответ.

Но, первое это не блокировка строк.

А что это?
Или вы к тому, что в случае

SELECT balance FROM users WHERE id = 1 LIMIT 1 FOR UPDATE;

происходит блокировка столбца balance, а не всей строки, а значит блокировкой строки называть это неправильно?
Объясните пожалуйста эту свою фразу. Не хотел бы ошибочно использовать неправильную терминологию.

Конкретно ваш кейс проще решается через ограничение на значение ниже нуля и обработка исключения в коде.

Согласен. Но для меня было важно убедиться в том, правильно ли я понимаю работу именно с блокировками. Так что моменты с ограничениями и прочим я намеренно опустил. Может для этого случая и не самый удачный пример выбрал, но постарался максимально упрощать.

[nApoBo3]

X110111, почитайте про типы блокировок. Эта тем достаточно объемная, быстро на пальцах не объясняется. Если кратко, блокировка строк, это блокировка конкретной строки, без блокировки других записей, заблокирует ли СУБД одну строку или "множество" зависит от различных, не всегда очевидных, условий. Т.е. просто написать запрос и сказать, что он заблокирует только одну строку, нельзя, этой информации не достаточно.