You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Как пользователь приложения я хочу, чтобы заказы на мои автомобили отслеживались и не допускались ситуации просрочки пользования автомобилем.
Основной сценарий
Время моего заказа на аренду автомобиля подходит к концу.
Сайт проверяет оплаченное время.
Если времени действительно больше нет - автомобиль помещается в каталог как свободный, а заказ на пользование автомобилем пропадает с личного кабинета заказавшего его пользователя. Владелец автомобиля видит же, что автомобиль стал снова доступен.
Проблема
Как программист я должен полностью предусмотреть механизм обработки таких ситуаций. Так как работа происходит с JSON файлами, которые в себя не включают подобного механизма, он должен быть написан на уровне приложения.
Наверное, единственным и самым правильным вариантом было бы использование дистанционного потока, который бы через какой-то заданный промежуток времени проходился бы по JSON файлу и менял статус заказов, если они были просрочены. Но, тут появляется задача: Ограничить доступ к файлу, чтоб работа с этим файлом производилась атомарно в рамках лишь одного потока. Казалось бы, можно использовать мьютексы, механизмы со взятием блокировки, тот же самый класс Monitor сыграл бы хорошую роль в этом деле...
Однако возникает проблема: данные необходимо менять сразу в нескольких репозиториях. То есть, если мы пробежались по файлу с заказами, поменяли их статусы, то вторым шагом будет являться взятие блокировки уже на файл с автомобилями для того, чтобы произвести смену их статуса на !IsOrdered (не заказан). Тут появляется подводный камень, что нам необходимо будет блокировать уже не один объект, а два. Помимо чтения, файл также нужно будет перезаписывать если хоть какие-то данные были изменены, что также требует немаленького количества времени. По факту, такой подход обязывает пользователя ждать выполнения проверки, перед тем, как получить, скажем, головную страницу с картой доступных автомобилей, каталог, страницу своего личного кабинета и так далее, так как все данные страницы берут некоторую информацию из JSON файлов с автомобилями и заказами. Таким образом, такой подход приведёт к синхронному выполнению задач по обработке файлов (Что у меня и реализовано сейчас, но без использования блокировок).
Таким образом, появляется задача: Как сделать алгоритм проверки на просроченные заказы максимально эффективно, чтоб это не приводило к задержкам на стороне пользователя (Чтоб пользователь не ждал в очереди, когда к нему придёт блокировка, в то время как дистанционный поток будет занят обработкой файла, к которому нам необходимо будет получить доступ).
p.s. По факту, блокировка будет браться на весь механизм работы с файлами, то есть на сам local repository. Таким образом какое-либо взаимодействие с ним будет блокироваться до момента получения заветной блокировки.
The text was updated successfully, but these errors were encountered:
Как пользователь приложения я хочу, чтобы заказы на мои автомобили отслеживались и не допускались ситуации просрочки пользования автомобилем.
Основной сценарий
Проблема
Как программист я должен полностью предусмотреть механизм обработки таких ситуаций. Так как работа происходит с JSON файлами, которые в себя не включают подобного механизма, он должен быть написан на уровне приложения.
Наверное, единственным и самым правильным вариантом было бы использование дистанционного потока, который бы через какой-то заданный промежуток времени проходился бы по JSON файлу и менял статус заказов, если они были просрочены. Но, тут появляется задача: Ограничить доступ к файлу, чтоб работа с этим файлом производилась атомарно в рамках лишь одного потока. Казалось бы, можно использовать мьютексы, механизмы со взятием блокировки, тот же самый класс Monitor сыграл бы хорошую роль в этом деле...
Однако возникает проблема: данные необходимо менять сразу в нескольких репозиториях. То есть, если мы пробежались по файлу с заказами, поменяли их статусы, то вторым шагом будет являться взятие блокировки уже на файл с автомобилями для того, чтобы произвести смену их статуса на !IsOrdered (не заказан). Тут появляется подводный камень, что нам необходимо будет блокировать уже не один объект, а два. Помимо чтения, файл также нужно будет перезаписывать если хоть какие-то данные были изменены, что также требует немаленького количества времени. По факту, такой подход обязывает пользователя ждать выполнения проверки, перед тем, как получить, скажем, головную страницу с картой доступных автомобилей, каталог, страницу своего личного кабинета и так далее, так как все данные страницы берут некоторую информацию из JSON файлов с автомобилями и заказами. Таким образом, такой подход приведёт к синхронному выполнению задач по обработке файлов (Что у меня и реализовано сейчас, но без использования блокировок).
Таким образом, появляется задача: Как сделать алгоритм проверки на просроченные заказы максимально эффективно, чтоб это не приводило к задержкам на стороне пользователя (Чтоб пользователь не ждал в очереди, когда к нему придёт блокировка, в то время как дистанционный поток будет занят обработкой файла, к которому нам необходимо будет получить доступ).
p.s. По факту, блокировка будет браться на весь механизм работы с файлами, то есть на сам local repository. Таким образом какое-либо взаимодействие с ним будет блокироваться до момента получения заветной блокировки.
The text was updated successfully, but these errors were encountered: