Отслеживание просроченных заказов #2
Description
Как пользователь приложения я хочу, чтобы заказы на мои автомобили отслеживались и не допускались ситуации просрочки пользования автомобилем.
Основной сценарий
- Время моего заказа на аренду автомобиля подходит к концу.
- Сайт проверяет оплаченное время.
- Если времени действительно больше нет - автомобиль помещается в каталог как свободный, а заказ на пользование автомобилем пропадает с личного кабинета заказавшего его пользователя. Владелец автомобиля видит же, что автомобиль стал снова доступен.
Проблема
Как программист я должен полностью предусмотреть механизм обработки таких ситуаций. Так как работа происходит с JSON файлами, которые в себя не включают подобного механизма, он должен быть написан на уровне приложения.
Наверное, единственным и самым правильным вариантом было бы использование дистанционного потока, который бы через какой-то заданный промежуток времени проходился бы по JSON файлу и менял статус заказов, если они были просрочены. Но, тут появляется задача: Ограничить доступ к файлу, чтоб работа с этим файлом производилась атомарно в рамках лишь одного потока. Казалось бы, можно использовать мьютексы, механизмы со взятием блокировки, тот же самый класс Monitor сыграл бы хорошую роль в этом деле...
Однако возникает проблема: данные необходимо менять сразу в нескольких репозиториях. То есть, если мы пробежались по файлу с заказами, поменяли их статусы, то вторым шагом будет являться взятие блокировки уже на файл с автомобилями для того, чтобы произвести смену их статуса на !IsOrdered (не заказан). Тут появляется подводный камень, что нам необходимо будет блокировать уже не один объект, а два. Помимо чтения, файл также нужно будет перезаписывать если хоть какие-то данные были изменены, что также требует немаленького количества времени. По факту, такой подход обязывает пользователя ждать выполнения проверки, перед тем, как получить, скажем, головную страницу с картой доступных автомобилей, каталог, страницу своего личного кабинета и так далее, так как все данные страницы берут некоторую информацию из JSON файлов с автомобилями и заказами. Таким образом, такой подход приведёт к синхронному выполнению задач по обработке файлов (Что у меня и реализовано сейчас, но без использования блокировок).
Таким образом, появляется задача: Как сделать алгоритм проверки на просроченные заказы максимально эффективно, чтоб это не приводило к задержкам на стороне пользователя (Чтоб пользователь не ждал в очереди, когда к нему придёт блокировка, в то время как дистанционный поток будет занят обработкой файла, к которому нам необходимо будет получить доступ).
p.s. По факту, блокировка будет браться на весь механизм работы с файлами, то есть на сам local repository. Таким образом какое-либо взаимодействие с ним будет блокироваться до момента получения заветной блокировки.