Комментарии 11
Решение без блокировок / ретраев и тюнинга изоляции
Пока читал до этого раздела, думал о том, нафига вообще все это нужно (транзакции, блокировки и т.д.). Ощущение было, что сами себе придумали трудности и сами героически их решили. В kafka ключи и группы потребителей не просто так придумали, они ровно для этого.
Понятно, что статья прежде всего обучающая, но, возможно, стоит сразу написать про этот способ. Горячие головы, не дочитав, могут погибнуть в неравном бою с блокировками.
Я что-то не понял, или проблему с лайками можно было починить просто написав вызов sql запроса навроде
UPDATE speakers SET likes = likes + <сколько_добавить> WHERE id = <кому>
?
Это старая тема для отдельного доклада, поставил лайк). Здесь результат будет зависеть от уровня изоляции транзакций, с рисками поймать dead lock при конкурентных апдейтах одной и той же строки. Подробнее, например, тут https://blog.pjam.me/posts/atomic-operations-in-sql/ .
Вообще мне показалось, что предложенное в статье решение это вариация на те же самые грабли, просто хорошо закопанные в Java. Но мне понравился сам подход автора, с проверками каждой своей гипотезы на стенде. Я чаще вижу когда начинающие разработчики удовлетворяются только мысленными экспериментами и собиранием потом граблей в продакшене.
В данном случае и пессимистическая блокировка на уровне строки (SELECT ... FOR UPDATE) не всегда помогает, если нужно обновлять несколько строк в одной транзакции. Нужно чётко следить за порядком строк, чтоб не нарваться на deadlock.
Надёжнее вынести код в хранимую процедуру PL/pgSQL и использовать блокировку критической секции кода при помощи pg_advisory_xact_lock() и т.п. Это как synchronized только в Postgres. В итоге имеем простейшую хранимку в пару строчек и транзакционную @Procedure в Repository спринга.
А что на счет application (advisory) lock в бд?
И на сколько часто случается, что по одному клиенту приходит столько сообщений, что происходит гонка?
Спасибо за статью. С точки зрения рассмотрения нюансов решения проблем в конкурентной обработки и использования транзакций - отлично, но с точки зрения проблемы вопрос: почему не рассматривали что-то а-ля CQRS или labmda подхода?
Есть сильно более простой вариант, что-то типа
update post set likes=likes+:rq_likes
, а ORM идет зад, т.к. делает дырявые абстракции
Напомнило : Если вы хотите приготовить яблочный пирог с нуля, сначала вы должны создать вселенную
А посоветуйте пожалуйста что почитать на тему правильного использования docker-compose в IDEA. В первую очередь интересует где и как все его файлы хранить, чтобы конфиги сервисов в контейнерах попадали в git, а вот файлы с данными (те же БД постгреса) нет. Ну и как все это настроить чтобы оно автоматом пересобирало контейнеры при изменении приложения. А то все ручками приходится делать по незнанию :-(
Используем аннотацию @Transactional like a pro