Я создаю PHP RESTful-API для удаленных «рабочих» машин для самостоятельного назначения задач. Таблица MySQL InnoDB на хосте API содержит ожидающие записи, которые рабочие могут получить из API, когда они будут готовы работать с записью. Как я могу предотвратить одновременное обращение рабочей системы к одной и той же записи?
Мой первоначальный план по предотвращению этого заключается в ОБНОВЛЕНИИ одной записи с уникальным сгенерированным идентификатором в поле NULL по умолчанию и последующем опросе для получения сведений о записи, где совпадает поле уникального идентификатора.
Например:
UPDATE mytable SET status = 'Assigned', uniqueidfield = '3kj29slsad'
WHERE uniqueidfield IS NULL LIMIT 1
И в том же экземпляре PHP, следующий запрос:
SELECT id, status, etc FROM mytable WHERE uniqueidfield = '3kj29slsad'
Результирующая запись из оператора SELECT выше передается работнику. Не помешает ли это одновременно запрашивать у работников одинаковые записи? Я не совсем уверен в том, как MySQL обрабатывает поиски в запросе UPDATE, и если два UPDATES могут «найти» одну и ту же запись, а затем обновить ее последовательно. Если это работает, есть ли более элегантный или стандартизированный способ сделать это (не уверен, что FOR UPDATE нужно будет применить к этому)? Спасибо!
Не берите в голову мой предыдущий ответ. Я верю, что понимаю, о чем вы спрашиваете. Я перефразирую это так, может быть, это будет понятнее другим.
«Что произойдет, если я выполню два из вышеприведенных операторов обновления одновременно?»
В соответствии с http://dev.mysql.com/doc/refman/5.0/en/lock-tables-restrictions.html, второе утверждение не помешает первому.
Как правило, вам не нужно блокировать таблицы, потому что все единственное ОБНОВЛЕНИЕ
заявления атомарны; никакой другой сеанс не может мешать другому
в настоящее время выполняется оператор SQL.
Более элегантный способ, вероятно, основан на мнении, но я не вижу ничего плохого в том, что вы делаете.
Других решений пока нет …