Комментарии 8
Это гарантирует проблемы с производительность в перспективе. Очень сложно вылавливаемые. Потратить неделю на то чтобы такое найти и вычистить из легаси кода который внезапно начал тормозить легко можно.
Оно еще и O(N) от количества локов работает. Так тоже нельзя.
И O(N^2) от количества элементов в локах. Так вообще нельзя.
А если у приложения несколько инстансов (процессов)?
Если вы такой фантастический параноик, то должны подумать о том, что бизнес-часть приложения когда-нибудь придется распараллелить на несколько инстансов для производительности и надёжности. Что креши и перезагрузки у бизнес-слоя приложения тоже бывают, и они не должны приводить к потере данных или возможности некорректной работы, из-за того что локи "потерялись". Поэтому и существует слой данных и транзакции. Оптимизировать в клиенте надо конечно, но не так.
Если брать вариант с такси, то можно было как вариант взять брокер сообщений типа Кафки и раскидать сообщения (о бронировании машины и отмене бронирования и т. д.) по партициям топика, где ключом будет идентификатор машины.
Фронт многопоточно, через слой API пишет в брокер сообщений сообщения, которые группируются в партии по ключу и хранятся согласно порядку ввода, а бэк может выгребать и обрабатывать эти сообщения тоже многопоточно. При этом скорость работы ограничена в основном числом партиций. И если инстанс, который обрабатывает текущее сообщение упал, то сообщение в брокере останется не прочитанных и следующий инстанс его штатно подберёт и обработает, главное чтобы весь процесс обработки в конкретном инстансе был реализован так, чтобы при падении не оставалось мусора в БД.
Про дедлок слышали? https://ru.wikipedia.org/wiki/%D0%92%D0%B7%D0%B0%D0%B8%D0%BC%D0%BD%D0%B0%D1%8F_%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0
Стоит модели и логике стать чуть сложнее — и вот вы уже висите в самый неподходящий момент. Если не нравятся тяжелые транзакции, посмотрите Software Transactional Memory.
Как синхронизировать сценарий без транзакций? Штатными средствами Java