Время ожидания или повторная активация записи БД в PHP - PullRequest
1 голос
/ 13 октября 2011

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

Как правило, когда пользователь попадает на страницу, он может вводить информацию для конкретной записи в базе данных. Пока он находится на этой странице, никакой другой пользователь не может получить доступ к этой конкретной записи. Когда он заканчивает, запись снова становится открытой. Теперь ограничить доступ к записи легко. Я настроил это так, что когда конкретная запись выбрана, значение в БД заявляет, что оно «Неактивно», и никто другой не может попасть на эту страницу. На самой странице есть кнопка «покинуть» и «отправить». Любой из них вернет запись в активное состояние.

Проблема в том, что пользователь решает щелкнуть по другой ссылке, закрыть вкладку или как-то уйти. Как я могу структурировать его, чтобы восстановить запись обратно в активное состояние? Я изучал событие onunload и, возможно, использовал его для вызова AJAX. Это самый логичный путь, или я упускаю что-то подобное из-за моих ограниченных знаний? Спасибо за вашу помощь.

Ответы [ 2 ]

0 голосов
/ 13 октября 2011

Я бы не пошел по пути onunload (по крайней мере, не исключительно), так как он ненадежен в случае сбоя, потери питания и т. Д. Скорее всего, в этом случае записи могут быть заблокированы «навсегда».

Я бы встраивал в страницу метод Ajax, который периодически запрашивает PHP-скрипт для «подтверждения» того, что страница еще жива.

Вы можете использовать такие «подтверждающие» запросы для сборки / обновлениятаблица для отслеживания текущих блокировок, работающая с s / t как lock_id, который однозначно идентифицирует блокируемую «запись», session_id, чтобы однозначно идентифицировать сеанс браузера, удерживающий эту блокировку, и expire_timestamp, чтобы установить время, в которое »запись "должна быть снова разблокирована, если больше не поступают запросы" подтверждения "session_id и поднимают ее expire_timestamp.

В сочетании с заданием cron, периодически удаляя записи, превышающие их expire_timestamp,это должно быть более надежным способом сделать то, что вы пытаетесь достичь.

0 голосов
/ 13 октября 2011

Я работал над аналогичной проблемой, и «onunload» - верный путь. Обратной стороной этого является то, что в случае сбоя или сбоя браузера (из диспетчера задач) выгрузка не вызывается. Поэтому лучше иметь задание, которое устанавливает записи в активное состояние, если его идентификатор сеанса, соответствующий этой записи, отсутствует. (вы также можете сохранить комбинацию sessionId и isactive lock для определения бездействия браузера)

...