с изменением имени?
Если нагрузка небольшая - то легче забить?
Если такое мб часто, то какой-нить оптимистик лок на таблицу и ретрай? Или очередь для последовательной обработки?
Помимо блокировок на таблицу целиком в рсубд есть ещё блокировки по полям/диапазонам. Достаточно повесить x-блокировку по почте, проверить её и осуществить запись.
чёт я не понимаю как у вас проверка вызывает лок делаете проверку селектом - нет имейла - и всё окей - персистаем пользователя в бд делаете проверку селектом - нет имейла - и всё окей - персистаем пользователя в бд даже если второму сначала сказали что такого нет мыла, и в этот момент произошла запись в бд - он отвалится потом на констрейнте в бд и точно также заворачиваем в кастомную ошибку и пишем - сорян такой уже занят в результате у пользователя два состояния - либо переходим в условно личный кабинет, потому что зарегались успешно либо перегружаем страничку с ошибкой - извините данное мыло уже занято, вот такой пароль у него)
Я не говорил, что проверка вызывает лок. Я говорил, что прийдется сделать лок, чтобы избежать ошибки аля race)
“даже если второму сначала сказали что такого нет мыла, и в этот момент произошла запись в бд - он отвалится потом на констрейнте в бд и точно также заворачиваем в кастомную ошибку и пишем - сорян такой уже занят” вот про это и был вопрос, как мне распознать эту ошибку в Spring Data, лезть и парсить SQL ошибки?
ну просто целиком всё в транзакцию заворачиваете "делаете проверку селектом - нет имейла - и всё окей - персистаем пользователя в бд" и да делаете лок
Обсуждают сегодня