Блокировать запись mysql при редактировании клиентом

Вступление:

1- Я не ищу кодового решения.

2- Я всего лишь прошу об образе мышления (алгоритме)

Описание проблемы:

1- У меня есть база данных mysql, запущенная на сервере.

2- База данных будет доступна для нескольких клиентов одновременно с помощью веб-приложения на базе php.

3- Если клиент A открывает запись recordIdX в веб-приложении, она будет отображаться в соответствующем html input fields, и у клиента будет время изменить эти значения перед отправкой form.

4- Проблема, которая может возникнуть, когда другой клиент B открывает тот же recordIdX, изменяет его и update базу данных до того, как клиент A завершит обновление.

Вопрос:

Как лучше всего предотвратить этот конфликт?

Что бы вы в итоге ни выбрали, вам нужно тщательно обдумать: что, если клиент A открывает запись, но никогда не редактирует / не закрывает ее?

Niet the Dark Absol 11.04.2018 13:21

«Я не ищу кодового решения». они почему тег PHP включен?

Raymond Nijland 11.04.2018 13:21

Я бы подумал о чем-то вроде хеширования записи и помещения ее в скрытое поле. Затем при сохранении проверьте, есть ли у записи тот же хэш. Если нет, значит, его отредактировал кто-то другой, и вам нужно разрешить конфликт.

Niet the Dark Absol 11.04.2018 13:21

«Как лучше всего предотвратить этот конфликт?» -> Используйте InnoDB в качестве механизма таблиц и включите FOR UPDATE в выбранный SELECT * FROM [TABLE] WHERE .... FOR UPDATE, таким образом, запись может быть обновлена ​​только первым клиентом, который открыл ее с помощью FOR UPDATE

Raymond Nijland 11.04.2018 13:27

Этот тип вопросов слишком широк и, возможно, основан на мнении. Я бы разместил это на обмене БД вместо dba.stackexchange.com - там вы получите лучший ответ.

Funk Forty Niner 11.04.2018 13:36

@RaymondNijland, почему бы вам не преобразовать ваш комментарий, связанный с InnoDB, в ответ?

mlwn 11.04.2018 14:54
1
6
95
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Одно разработанное мной веб-приложение имело аналогичное требование. Вот как я это сделал:

Таблицы, которые должны быть «запираемыми», имеют столбец accessId. accessId был внешним ключом для таблицы access, в которой были некоторые соответствующие столбцы, например: isLocked, isLockedByUserId, lastModificationDate, ...

Это тоже может быть интересно: Оптимистическая и пессимистическая блокировка

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

Raymond Nijland 11.04.2018 13:28

Пессимистическая блокировка @RaymondNijland предотвратит состояние гонки

N. D. 11.04.2018 13:30

Лучший вариант, который есть у автора темы, - использовать InnoDB и FOR UPDATE и позволить базе данных обрабатывать блокировку.

Raymond Nijland 11.04.2018 13:31

1 или 2 дополнительных поля (lock guid, timestamp) можно использовать вместо другой таблицы, но в остальном это единственное решение. FOR UPDATE должен использоваться, чтобы гарантировать атомарную блокировку.

Vatev 11.04.2018 13:50

@Vatev, я на самом деле следовал вашему мнению, используя только одно поле isopen .. Мне не нужна дополнительная информация ... если он установлен на 0, установите его на 1 и откройте запись ... в противном случае, выведите эхо-сообщение в это поле, которое уже находится в использовать...

mlwn 11.04.2018 17:32

@mlwn, как узнать, у какого клиента есть блокировка, а кому нужно ждать? Также вам понадобится метка времени и тайм-аут блокировки. В противном случае запись может (и будет) навсегда заблокирована после сбоя сети, сбоя и т. Д.

Vatev 12.04.2018 09:11

@Vatev, у меня уже есть другая переменная с идентификатором клиента, который вошел в систему. Итак, если поле islocked - это 0, никто не использует это поле .. в противном случае я помещаю идентификатор клиента в это поле e.g. 4 для идентификатора клиента 4 ... любой пользователь, который хочет использовать поле, получит сообщение о том, что поле заблокировано идентификатором клиента 4. Если оно было заблокировано после сбоя сети, идентификатор клиента 4 все еще может открыть поле и закрыть его в обычном режиме, что разблокирует его. .. это в основном больше, чем мне нужно ..

mlwn 12.04.2018 12:47

Другие вопросы по теме