Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
 Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ahmaroot
Member

Откуда:
Сообщений: 11
Всем доброго дня.
Входные данные:
БД на Mysql 5.7, innodb
Приложение на PHP 7.4
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)


Конечно же, сразу хочется заюзать пессимистик лок (а ля select for update и все это в рамках транзакции). Но появились в нашей команде такие, кто против этого и вместо блокировки записи предлагает просто при update делать что-то вроде:
update table set amount = amount + someValue;

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


Подскажите пожалуйста, поделитесь мнением. Интересна критика подхода без блокировки.
28 мар 21, 14:47    [22301083]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ViPRos
Member

Откуда:
Сообщений: 9943
ahmaroot,

именно это (добавить что-то тому что есть в в момент добавления) не требует блокировки
а вот (добавить что-то тому что есть в в момент добавления) так ли это?
обычно то что добавляется вычисляется исходя из "тому что есть" в другом моменте времени
28 мар 21, 15:04    [22301087]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 2511
>ahmaroot, сегодня, 14:47 [22301083]
>Делается чтение записи ... сразу хочется заюзать пессимистик лок
<
Рассмотрите варианты с двумя пользователями:
Предлагаемый
1. Пользователь читает запись
2. Анализирует запись
3. Делает изменения.
Ваш вариант
0. Блокирует запись
1. Пользователь читает запись
2. Анализирует запись
3. Делает изменения
4. Деблокирует запись.
Рассмотрите длительность пункта 2. И что будет делать второй пользователь?
На мой взляд лучше оптимистическая блокировка
28 мар 21, 18:58    [22301151]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
irbis_al
Member

Откуда: Симферополь
Сообщений: 1797
ahmaroot
Всем доброго дня.
Входные данные:
БД на Mysql 5.7, innodb
Приложение на PHP 7.4
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)


Конечно же, сразу хочется заюзать пессимистик лок (а ля select for update и все это в рамках транзакции). Но появились в нашей команде такие, кто против этого и вместо блокировки записи предлагает просто при update делать что-то вроде:
update table set amount = amount + someValue;

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


Подскажите пожалуйста, поделитесь мнением. Интересна критика подхода без блокировки.


Те,кто Вам такое предлагают,- договоритесь на берегу...Когда у конторы "уйдут" деньги...из-за такой неблокирующей транзакции,- недостачу покроет тот умник ,который не хочет делать select for update;
28 мар 21, 19:20    [22301156]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
booby
Member

Откуда:
Сообщений: 2534
ahmaroot
...Интересна критика подхода без блокировки.

это правильный подход.
Интересно должно быть только собственное мнение и благосклонно допускаются поддакивания ему.
Вот смотри - даже чудаки с sql.ru, так же как и я, в этом вопросе не разбираются.
Значит, все мы вместе - правы.

Сообщение было отредактировано: 28 мар 21, 21:20
28 мар 21, 21:23    [22301185]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ahmaroot
Member

Откуда:
Сообщений: 11
booby
ahmaroot
...Интересна критика подхода без блокировки.

это правильный подход.
Интересно должно быть только собственное мнение и благосклонно допускается поддакивания ему.
Вот смотри - даже чудаки с sql.ru, так же как и я, в этом вопросе не разбираются.
Значит, все мы вместе - правы.


А можете аргументировать, если не сложно? Буду благодарен. Просто как по мне, при блокировки на уровне БД, мы также лочим запись и от других "клиентов" (систем, имею ввиду), не только от текущей. А т.к. тема касается финансов, то как по мне, очень странно тут НЕ блокировать запись.
28 мар 21, 21:27    [22301187]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
booby
Member

Откуда:
Сообщений: 2534
ahmaroot,

что тут аргументировать?
вся тема в целом называется проблемой потерянных обновлений (lost updates).
Именно в этом сценарии для субд, нормально спроектированных для многопользовательской работы, она не возникает ни при каком уровне изоляции.

"Нормальна" ли в этом смысле InnoDb - я не знаю, но вам проверить это гораздо быстрее, чем буквы в форум набирать.
28 мар 21, 21:33    [22301190]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
ahmaroot,

при нынешних возможностях - говорить о блокировках на уровне бд несколько странно.
ведь есть ws и блокировать можно напрямую у клиента.
первый зашедший в запись блокирует изменение данной записи у всех клиентов с отображением цветом (как вариант)

про блокировки
https://habr.com/ru/post/238513/

Сообщение было отредактировано: 28 мар 21, 21:37
28 мар 21, 21:37    [22301191]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 2511
>вадя, сегодня, 21:37 [22301191]
>...первый зашедший в запись блокирует изменение...
<
а если так (как вариант):
1. в любой записи таблицы есть поле, содержащее текущее значение версии записи (MSSQL - timestamp, PostgreSql - int8)
2. любой пользователь в любой момент может считать запись и сколько угодно времени "урчать" над ней.
3. <начало транзакции> в момент изменения сравниваются версии записи - текущая и пользовательская.
Если равны - изменения принимаются, генерируется новое значение версии для записи. <фиксация>
Иначе <откат>
Текущая запись с признаком штатно/ошибка возвращается пользователю.
28 мар 21, 23:57    [22301225]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
hVostt
Member

Откуда:
Сообщений: 19317
ahmaroot
Подскажите пожалуйста, поделитесь мнением. Интересна критика подхода без блокировки.


Какую задачу решаете?

Если можно обойтись без блокировки -- надо обойтись без блокировки.
Отсутствие блокировок -- значит хороший дизайн, вы решили задачу наилучшим образом.


ВМоисеев
Текущая запись с признаком штатно/ошибка возвращается пользователю.


Такой дизайн, например, является доисторическим колхозом, если вы делаете программу для людей, подобного нужно избегать, ибо УГ.
29 мар 21, 01:26    [22301238]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
hVostt
Member

Откуда:
Сообщений: 19317
вадя
ведь есть ws и блокировать можно напрямую у клиента.


Кто про что, а вшивый про баню
29 мар 21, 01:27    [22301239]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
miksoft
Member

Откуда:
Сообщений: 38826
ahmaroot
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)


Конечно же, сразу хочется заюзать пессимистик лок (а ля select for update и все это в рамках транзакции).
А как обеспечивается, чтобы чтение и update происходили в одной сессии MySQL?
29 мар 21, 02:17    [22301241]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 2511
>hVostt, сегодня, 01:26 [22301238]
>...является доисторическим колхозом...
1. Чем же Вам так насолила оптимистическая блокировка?
2. Ваш вариант решения вопроса в студию.
29 мар 21, 11:24    [22301322]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 2511
>hVostt, сегодня, 01:27 [22301239]
>Кто про что, а вшивый про баню.
<
Вы работали с PostgreSQL?
Здесь транзакцию приходится включать на клиенте. Почему не работать и с блокировками здесь?
29 мар 21, 11:34    [22301335]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
hVostt
Member

Откуда:
Сообщений: 19317
ВМоисеев
>hVostt, сегодня, 01:26 [22301238]
>...является доисторическим колхозом...
1. Чем же Вам так насолила оптимистическая блокировка?
2. Ваш вариант решения вопроса в студию.


Почему мне должно было что-то насолить?
Хорошее решение -- обойтись без блокировки.

Мы уже 100500 раз обсуждали этот вопрос в других топиках.

Сообщение было отредактировано: 29 мар 21, 12:00
29 мар 21, 12:07    [22301356]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
hVostt
Member

Откуда:
Сообщений: 19317
ВМоисеев
Здесь транзакцию приходится включать на клиенте. Почему не работать и с блокировками здесь?


Наверное потому что конечный клиент в современных системах не работает с СУБД напрямую. Время двухзвенок давным-давно прошло.
29 мар 21, 12:07    [22301357]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53394
ahmaroot
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)

Это явный признак неправильного дизайна базы. Присоединяюсь к вопросу "а назачем, собственно", заданному выше.
29 мар 21, 14:03    [22301419]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 2511
>hVostt, сегодня, 12:07 [22301357]
>...Время двухзвенок давным-давно прошло.
<
Могет быть, могет быть. Для сферы купли/продажи, рекламы, досуга и т.п. - да.
Но эти господа продолжают свою линию гнуть.
29 мар 21, 14:10    [22301427]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
ВМоисеев
а если так (как вариант):
тут фишка не в базе, а в том. что блокируется у клиента возможность изменить. грубо - отключаются инпуты.
hVostt
Кто про что, а вшивый про баню
я в своё время намаялся с этим. поэтому для меня такая возможность - просто радость.
29 мар 21, 18:00    [22301604]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 2511
>вадя, сегодня, 18:00 [22301604]
>...блокируется у клиента возможность изменить
<
Нет. У ВСЕХ клиентов, что есть не приемлемо.
29 мар 21, 19:07    [22301638]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
ВМоисеев,

блокируется у всех, кроме первого, который и начал изменение. и они видят, что они заблокированы.
30 мар 21, 00:58    [22301773]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
ВМоисеев,

-- блокируется у клиента --
имелось в виду, что блокировка происходит на фронте, а не на сервере
30 мар 21, 01:02    [22301775]     Ответить | Цитировать Сообщить модератору
 Re: Песимистичная блокировка - стоит ли юзать в данном кейсе?  [new]
L_argo
Member

Откуда:
Сообщений: 1473
Па сабжу: попробуйте оба варианта. Потом оставьте самый успешный. :)

Как вариант - делать сабж асинхронно единым регламентным заданием, которое само себя не заблокирует.
30 мар 21, 09:06    [22301815]     Ответить | Цитировать Сообщить модератору
Все форумы / Разработка информационных систем Ответить