блокировка записей многопользовательских приложений – лучший метод?

Question

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

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

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

Я предполагаю, что должна быть какая-то форма ajax, чтобы «пинговать» приложение и сообщать ему, что запись все еще просматривается/редактируется (в противном случае пользователь может просто закрыть окно браузера, и тогда как приложение узнает об этом).

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

Возможно, я иду не по тому дереву с точки зрения решения - каков опыт людей по реализации этого (что должно быть довольно распространенным) требованием?

Answer 1

Я бы сделал это:Сохраните время последнего изменения в форме редактирования.Сравните это время при отправке со временем, хранящимся в базе данных.Если они совпадают, заблокируйте таблицу, обновите данные (вместе со временем изменения) и разблокируйте таблицу.Если время другое, сообщите об этом пользователю и попросите выполнить следующий шаг.

Answer 2

видеть: Что я могу сделать, чтобы предотвратить конфликты записи на веб-сайте в стиле вики?

Answer 3

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

Возможно, стоит рассмотреть возможность сохранения имени пользователя при каждом обновлении в поле, называемом чем-то вроде «LastUpdateBy», и вернуть его обратно пользователю, у которого было предварительное обновление.Немного приятности для пользователя.Приятно в корпоративном смысле, но, возможно, не в среде, где это может быть неуместно.