Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Песимистичная блокировка - стоит ли юзать в данном кейсе? / 23 сообщений из 23, страница 1 из 1
28.03.2021, 14:47
    #40057547
ahmaroot
ahmaroot
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
Всем доброго дня.
Входные данные:
БД на Mysql 5.7, innodb
Приложение на PHP 7.4
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)


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


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


Подскажите пожалуйста, поделитесь мнением. Интересна критика подхода без блокировки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 15:04
    #40057549
ViPRos
ViPRos
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot,

именно это (добавить что-то тому что есть в в момент добавления) не требует блокировки
а вот (добавить что-то тому что есть в в момент добавления) так ли это?
обычно то что добавляется вычисляется исходя из "тому что есть" в другом моменте времени
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 18:58
    #40057584
ВМоисеев
ВМоисеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
>ahmaroot, сегодня, 14:47 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301083][22301083]
>Делается чтение записи ... сразу хочется заюзать пессимистик лок
<
Рассмотрите варианты с двумя пользователями:
Предлагаемый
1. Пользователь читает запись
2. Анализирует запись
3. Делает изменения.
Ваш вариант
0. Блокирует запись
1. Пользователь читает запись
2. Анализирует запись
3. Делает изменения
4. Деблокирует запись.
Рассмотрите длительность пункта 2. И что будет делать второй пользователь?
На мой взляд лучше оптимистическая блокировка
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 19:20
    #40057588
irbis_al
irbis_al
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot
Всем доброго дня.
Входные данные:
БД на Mysql 5.7, innodb
Приложение на PHP 7.4
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)


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


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


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


Те,кто Вам такое предлагают,- договоритесь на берегу...Когда у конторы "уйдут" деньги...из-за такой неблокирующей транзакции,- недостачу покроет тот умник ,который не хочет делать select for update;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 21:23
    #40057607
booby
booby
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot
...Интересна критика подхода без блокировки.

это правильный подход.
Интересно должно быть только собственное мнение и благосклонно допускаются поддакивания ему.
Вот смотри - даже чудаки с sql.ru, так же как и я, в этом вопросе не разбираются.
Значит, все мы вместе - правы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 21:27
    #40057608
ahmaroot
ahmaroot
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
booby
ahmaroot
...Интересна критика подхода без блокировки.

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


А можете аргументировать, если не сложно? Буду благодарен. Просто как по мне, при блокировки на уровне БД, мы также лочим запись и от других "клиентов" (систем, имею ввиду), не только от текущей. А т.к. тема касается финансов, то как по мне, очень странно тут НЕ блокировать запись.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 21:33
    #40057611
booby
booby
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot,

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

"Нормальна" ли в этом смысле InnoDb - я не знаю, но вам проверить это гораздо быстрее, чем буквы в форум набирать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 21:37
    #40057612
вадя
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot,

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

про блокировки
https://habr.com/ru/post/238513/
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.03.2021, 23:57
    #40057631
ВМоисеев
ВМоисеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
>вадя, сегодня, 21:37 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301191][22301191]
>...первый зашедший в запись блокирует изменение...
<
а если так (как вариант):
1. в любой записи таблицы есть поле, содержащее текущее значение версии записи (MSSQL - timestamp, PostgreSql - int8)
2. любой пользователь в любой момент может считать запись и сколько угодно времени "урчать" над ней.
3. <начало транзакции> в момент изменения сравниваются версии записи - текущая и пользовательская.
Если равны - изменения принимаются, генерируется новое значение версии для записи. <фиксация>
Иначе <откат>
Текущая запись с признаком штатно/ошибка возвращается пользователю.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 01:26
    #40057642
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot
Подскажите пожалуйста, поделитесь мнением. Интересна критика подхода без блокировки.


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

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


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


Такой дизайн, например, является доисторическим колхозом, если вы делаете программу для людей, подобного нужно избегать, ибо УГ.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 01:27
    #40057643
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
вадя
ведь есть ws и блокировать можно напрямую у клиента.


Кто про что, а вшивый про баню
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 02:17
    #40057644
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)


Конечно же, сразу хочется заюзать пессимистик лок (а ля select for update и все это в рамках транзакции).
А как обеспечивается, чтобы чтение и update происходили в одной сессии MySQL?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 11:24
    #40057704
ВМоисеев
ВМоисеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
>hVostt, сегодня, 01:26 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301238][22301238]
>...является доисторическим колхозом...
1. Чем же Вам так насолила оптимистическая блокировка?
2. Ваш вариант решения вопроса в студию.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 11:34
    #40057715
ВМоисеев
ВМоисеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
>hVostt, сегодня, 01:27 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301239][22301239]
>Кто про что, а вшивый про баню.
<
Вы работали с PostgreSQL?
Здесь транзакцию приходится включать на клиенте. Почему не работать и с блокировками здесь?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 12:07
    #40057733
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ВМоисеев
>hVostt, сегодня, 01:26 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301238][22301238]
>...является доисторическим колхозом...
1. Чем же Вам так насолила оптимистическая блокировка?
2. Ваш вариант решения вопроса в студию.


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

Мы уже 100500 раз обсуждали этот вопрос в других топиках.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 12:07
    #40057734
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ВМоисеев
Здесь транзакцию приходится включать на клиенте. Почему не работать и с блокировками здесь?


Наверное потому что конечный клиент в современных системах не работает с СУБД напрямую. Время двухзвенок давным-давно прошло.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 14:03
    #40057774
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ahmaroot
Делается чтение записи, небольшая калькуляция и update записи с целью изменить поле amount (с деньгами)

Это явный признак неправильного дизайна базы. Присоединяюсь к вопросу "а назачем, собственно", заданному выше.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 14:10
    #40057782
ВМоисеев
ВМоисеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
>hVostt, сегодня, 12:07 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301357][22301357]
>...Время двухзвенок давным-давно прошло.
<
Могет быть, могет быть. Для сферы купли/продажи, рекламы, досуга и т.п. - да.
Но эти господа продолжают свою линию гнуть.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 18:00
    #40057925
вадя
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ВМоисеев
а если так (как вариант):
тут фишка не в базе, а в том. что блокируется у клиента возможность изменить. грубо - отключаются инпуты.
hVostt
Кто про что, а вшивый про баню
я в своё время намаялся с этим. поэтому для меня такая возможность - просто радость.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.03.2021, 19:07
    #40057950
ВМоисеев
ВМоисеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
>вадя, сегодня, 18:00 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1334741&msg=22301604][22301604]
>...блокируется у клиента возможность изменить
<
Нет. У ВСЕХ клиентов, что есть не приемлемо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.03.2021, 00:58
    #40058044
вадя
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ВМоисеев,

блокируется у всех, кроме первого, который и начал изменение. и они видят, что они заблокированы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.03.2021, 01:02
    #40058046
вадя
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
ВМоисеев,

-- блокируется у клиента --
имелось в виду, что блокировка происходит на фронте, а не на сервере
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.03.2021, 09:06
    #40058079
L_argo
L_argo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Песимистичная блокировка - стоит ли юзать в данном кейсе?
Па сабжу: попробуйте оба варианта. Потом оставьте самый успешный. :)

Как вариант - делать сабж асинхронно единым регламентным заданием, которое само себя не заблокирует.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Песимистичная блокировка - стоит ли юзать в данном кейсе? / 23 сообщений из 23, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 378ms
Закрыть
start [/forum/topic.php?fid=33&mobile=1&tid=1547064]:
 0ms
get settings:
 11ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 40ms
get topic data:
 14ms
get forum data:
 2ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 233ms
total:  378ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]