Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Отслеживание просроченных заказов #2

Open
GlebTheProgrammer opened this issue Nov 28, 2022 · 0 comments

Comments

@GlebTheProgrammer
Copy link
Owner

Как пользователь приложения я хочу, чтобы заказы на мои автомобили отслеживались и не допускались ситуации просрочки пользования автомобилем.

Основной сценарий

  1. Время моего заказа на аренду автомобиля подходит к концу.
  2. Сайт проверяет оплаченное время.
  3. Если времени действительно больше нет - автомобиль помещается в каталог как свободный, а заказ на пользование автомобилем пропадает с личного кабинета заказавшего его пользователя. Владелец автомобиля видит же, что автомобиль стал снова доступен.

Проблема

Как программист я должен полностью предусмотреть механизм обработки таких ситуаций. Так как работа происходит с JSON файлами, которые в себя не включают подобного механизма, он должен быть написан на уровне приложения.

Наверное, единственным и самым правильным вариантом было бы использование дистанционного потока, который бы через какой-то заданный промежуток времени проходился бы по JSON файлу и менял статус заказов, если они были просрочены. Но, тут появляется задача: Ограничить доступ к файлу, чтоб работа с этим файлом производилась атомарно в рамках лишь одного потока. Казалось бы, можно использовать мьютексы, механизмы со взятием блокировки, тот же самый класс Monitor сыграл бы хорошую роль в этом деле...

Однако возникает проблема: данные необходимо менять сразу в нескольких репозиториях. То есть, если мы пробежались по файлу с заказами, поменяли их статусы, то вторым шагом будет являться взятие блокировки уже на файл с автомобилями для того, чтобы произвести смену их статуса на !IsOrdered (не заказан). Тут появляется подводный камень, что нам необходимо будет блокировать уже не один объект, а два. Помимо чтения, файл также нужно будет перезаписывать если хоть какие-то данные были изменены, что также требует немаленького количества времени. По факту, такой подход обязывает пользователя ждать выполнения проверки, перед тем, как получить, скажем, головную страницу с картой доступных автомобилей, каталог, страницу своего личного кабинета и так далее, так как все данные страницы берут некоторую информацию из JSON файлов с автомобилями и заказами. Таким образом, такой подход приведёт к синхронному выполнению задач по обработке файлов (Что у меня и реализовано сейчас, но без использования блокировок).

Таким образом, появляется задача: Как сделать алгоритм проверки на просроченные заказы максимально эффективно, чтоб это не приводило к задержкам на стороне пользователя (Чтоб пользователь не ждал в очереди, когда к нему придёт блокировка, в то время как дистанционный поток будет занят обработкой файла, к которому нам необходимо будет получить доступ).

p.s. По факту, блокировка будет браться на весь механизм работы с файлами, то есть на сам local repository. Таким образом какое-либо взаимодействие с ним будет блокироваться до момента получения заветной блокировки.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant