это вообще довольно характерная тема. ты точно уверен, что тебе это нужно? остальные клиенты ведь будут ждать (а они, может, вовсе по другим вопросам в таблице). и потом, зависит от базы. в мусе и постгре это ощутимо разные процедуры. ну и самое главное — тебе мало залочить таблицу, нужно еще её разлочить как при положительном исходе, так и при отрицательном. это не самая тривиальная задача, я тебе скажу.
А что тогда делать, чтобы избежать race condition?
транзакции изучать, епта. лочить таблицу нужно только тогда, когда ты меняешь саму таблицу или все её записи
Создай тупо глобальную переменную Bool, и пропусти свой метод через нее. Пока не true обращаться к базе нельзя. Или у тебя проект уже на миллион долларов?
Насколько понял, у бд есть своя очередь для транзакций?
Неправильно было бы называть это очередью для транзакций. В базах данных имеет место механизм сериализации, из названия подразумевается организация последовательности доступа к ресурсам. Как правило, если запрос пытается получить доступ к ресурсу (ну, записи в базе), который уже эксклюзивно занят другим процессом, то он получает отлуп. Муся и постгре почему-то называют это дедлоком, что неверно, это ведь всего лишь таймаут сериализации. ЖДАТЬ, пока доступ освободится, не надо (ты же занимаешь тред), а вот поретраить этот запрос очень даже можно (и нужно), только не до бесконечности
Может не увидел вопрос, повторю Я вот одного не могу понять - вот у меня 50 одновременных запросы на добавление, и в каждом считается количество в группе. Тоесть, для одного из запросов надо будет 50 раз повторить?
Обсуждают сегодня