Если Вы сделаете два запроса на один контроллер, то у Вас будут два разных инстанса контроллера и соответственно разные объекты сервисов. При дебаге Вам может показаться, что заходит в один метод два потока, но каждый поток заходит в метод своего объекта. Соответственно там будут и разные инстансы dbContext.
Это я понимаю
Первое, что приходит на ум, это впихнуть нутро AddOrder в транзакцию, с уровнем, который ограничивает изменение данных.
Соглашусь, очередь решит проблему, есть опыт в использовании rabbitmq
Уточню проблему: что если нет задачи гарантировать все запросы от пользователя и выполнить из друг за другом, а хотя бы выполнять в текущий момент только один запрос, остальные игнорировать.
Пример тот же - два запроса с клиента.
может даже не быть потоков как таковых: флаг, запрещающий создавать\обрабатывать заказы, при наличии неотработанного заказа у пользователя
Допустим мы делаем проверку - запрос в хранилище по этому юзеру
Но это будут одновременно делать два потока и каждый получит верный результат проверки
OrderService резолвится НЕ как синглтон (в конце сообщения указал)
Тем не менее, будет несколько потоков, одновременно выполняющих один и тот же код. Попробуйте сами через консоль отправить вместе два $.post)
Дизейбл кнопки - само собой. Но не решение, т.к. если полагаться только на это, есть потенциальная уязвимость, запросы то можно и программно слать
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Это я понимаю
Надо попробовать, спасибо!