Потому что данные принято хранить в БД? Чего это не домен, это транзакция, самый что ни на есть домен
есть бизнес модели, а есть модели уровня разработки. Все в бд хранить?
Модели уровня разработки - что это?
а скорость, будет аргументом?
В контексте транзакций думаю главным будет надёжность в первую очередь
нам нужно хранить данные в контексте нажатия кнопки, нам эти данные при закрытом приложении ни к чему. зачем это хранить в бд?
Стоп стоп. Почему в контексте нажатия кнопки? Это ж часть транзакции, она существует всегда. У неё есть какой то жизненный цикл
зачем информация о синхронизации обработки транзакции нужно в бд, если кроме момента синхронизации эти данные нигде использованы не будут?
Там не инфа о синхронизации, а инфа о состоянии транзакции. Где кем и когда подтверждена
ок, вот добавили мы флаг в сущность транзакции и том что она обрабатывается. Где гарантии что установка этого флага не будет выполнена одновременно 2мя пользователями. Как вы себе представляете процесс синхронизации этого действия?
Там не флаг, там видимо enum как множество состояний. Гарантия на уровне транзакций в БД, к примеру. Я не знаком близко с этим, но запрос вида 'Update set InProcess = true Where Id = 7 and InProcess = false' гарантирует, что выставится один раз. И вернёт количество затронутых строк
проблема в том, что этот query по логике должен быть вызван уже после проверки этого флага. Т.е. 2 около одновременных запросов пройдут условие до того как данные в БД сохранятся. Ок возьмем даже если этот query выполнится за 20 мс, 20 мс в контексте одного http запроса это слишком много для синхронизации чтобы быть уверенным что это поможет. У меня была такая ситуация, решалось как я и писал выше, через ConcurrentDictionary.
Обсуждают сегодня