2016-10-03 8 views
0

Мы пытаемся создать алгоритм/эвристику, которая будет планировать доставку в определенный период времени, но здесь определенно есть условие гонки, в результате чего два конфликтующих запланированных элемента могут быть написанный в БД, потому что запись не является атомной.Избегайте условия гонки для вставки модели в БД на сложных условиях

Единственный способ по-настоящему предотвратить условия гонки - создать некоторую операцию с атомной вставкой, TMK.

Сервер получает запрос на планирование чего-либо в течение определенного периода времени, и сервер должен проверить, доступен ли этот период времени, прежде чем он записывает данные в БД. Но в то время сервер мог получить аналогичный запрос и в конечном итоге написать конфликтующие данные.

Как обходить это? Есть ли способ создать какой-либо скрипт в самой БД, который перехватывает операцию записи, чтобы сделать все это атомом? Поместив механизм блокировки на этот скрипт? То, что делает все неатомное, - это чтение и время проводов между сервером и БД.

+2

Похоже, что у вас возникают проблемы с созданием конкретной работы с кодом. В этом случае мы можем быть более полезными, если вы разместите [минимальный код, воспроизводящий проблему] (http://stackoverflow.com/help/mcve). –

+1

этот вопрос может принадлежать программистам.stackexchange? –

ответ

2

Всякий раз, когда я сталкиваюсь с состоянием гонки, я думаю об одном немедленном решении QUEUE.

Шаг 1) Что вы можете сделать, так это то, что вместо добавления данных в базу данных вы можете добавить их в очередь, не проверив ничего.

Шаг 2) Отдельный считыватель прочитает из БД проверки очереди для любого конфликта и предпримет необходимые действия.

Это один из способов решить эту проблему. Если вы реализуете любое лучшее решение, пожалуйста, разделите его.

Надеюсь, что поможет

+0

спасибо за ответ, я на самом деле не уверен, как это решает проблему. (1) Два работника в одной очереди могли получить аналогичный запрос за короткий промежуток времени, (2) оба работника могли читать из БД и видеть, что запись была прекрасной, (3) оба работника пишут в сбора и эффективно вызывать конфликт данных на высоком уровне. –

+0

единственный способ избежать вышеизложенного - это если сама запись (3) является атомной операцией в БД. проблема в том, что запись в нашей БД не является атомарной, она зависит от большего количества условий, чем только одно поле в БД, а что нет. –

+0

Можете ли вы более точно описать, как очередь решит проблему? благодаря! –