Я продал одно место на концерт 20 раз. Разбираемся, как правильно защититься от race condition в Spring Boot

[Dhwtj]

Я продал одно место на концерт 20 раз.

А где минусы?

[GoshaPetrov]

Минусы только у комментария пока что 😄

[xSVPx]

353мс выглядят совершенно чудовищной цифрой. Или это для последнего из 50 потоков ?

Как-то странно соотносятся мин-макс, по идее должен быть ведь гораздо больший разбег.

[GoshaPetrov]

Это цифры из Gatling burst-теста на 200 одновременных запросов

[kmatveev]

Причина в том, что UPDATE в Postgres всегда берёт эксклюзивную блокировку строки на время транзакции — это встроенное поведение MVCC, а не наша логика. Конкурирующие записи в одну строку физически выстраиваются в очередь.

Что за чушь, нет в Postgres при простых обновлениях никаких блокировок строки, тупо появляются новые версии. Другое дело, что коммиты транзакций происходят последовательно, и та версия строки, которая соответствует транзакции, которая закоммичена последней, и будет видна следующим читателям. Или у вас serialized-транзакции?

[ris58h]

Текст очевидно сгенерирован, поэтому и чушь.

[XelaVopelk]

век живи, век учись. Пример:

The FOR UPDATE lock mode is also acquired by any DELETE on a row, and also by an UPDATE that modifies the values of certain columns. Currently, the set of columns considered for the UPDATE case are those that have a unique index on them that can be used in a foreign key (so partial indexes and expressional indexes are not considered), but this may change in the future.

https://www.postgresql.org/docs/current/explicit-locking.html

[GoshaPetrov]

Спасибо!

[tstabs]

Как альтернатива для SELECT FOR UPDATE - использовать advisory locks (pg_advisory_xact_lock).
Из плюсов: для Spring Data не нужно дублировать методы findBy с @Lock, автоматически снимается в конце транзакции, не пишет в WAL (но возможно это несущественно).
Естественно, это не защищает от прямого UPDATE, поэтому нужно использовать в каждом методе сервиса, который модифицирует объект.

[GoshaPetrov]

Спасибо большое! Не знал про этот способ, посмотрю.

[XelaVopelk]

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

Т.е. если если у меня несколько инстансов сервиса мне надо использовать redis? Господи, где ж я так согрешил то?

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

[GoshaPetrov]

Да, тут неправильно выразился, спасибо 😅
Если БД общая, то все прекрасно будет работать, Redis не нужен просто из-за количества инстансов приложения, поправлю.

[SergeyPerm]

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

я когда-то давно пилил очередь через UPDATE ... RETURING этого было более чем достаточно, никаких транзакций открывать не надо, сам запрос атомарный, обновлял только одну запись, соответствующую условию, в сотни параллельных запросов без всяких накладок.