Здравствуйте, хочу реализовать избежание параллейного редактирования одной и той же записи.
Логика:
1. Создаем переменную с датой и временем.
2. Отправляем запрос в БД на выдачу записи.
3. Сверяем созданную дату и запись в БД, если запись БД имеет пустую дату, то
3.1 выводим данные (после вывода, записываем дату конца редактирования записи (+5 минут)), если
3.2 дата записи БД имеет данные, то сверяем их с текущей датой (пункт 1), если
3.3 дата записи меньше, чем действительная, то выводим "просьбу повторить попытку позже" иначе
3.4 выдаем данные пользователю (после вывода, записываем дату конца редактирования записи (+5 минут)).
--
PS: Возможно стоит использовать сессию и проверять её существование, а не играть с датами?
1. LEONeso - 27 Июня, 2011 - 02:27:57 - перейти к сообщению
2. DeepVarvar - 27 Июня, 2011 - 07:34:27 - перейти к сообщению
LEONeso MySQL имеет возможность блокировать таблицы?
Я делал так:
Создавал специальный лок-файл, в него ничего не пишется, из него ничего не читается.
Он просто блокируется. Дальше совершаем любые действия - меняем/удаляем/добавляем контент...
В конце снимаем с файла блокировку.
Пока скрипт залочивший файл не отработает - остальные будут стоять на очереди.
flock
Я делал так:
Создавал специальный лок-файл, в него ничего не пишется, из него ничего не читается.
Он просто блокируется. Дальше совершаем любые действия - меняем/удаляем/добавляем контент...
В конце снимаем с файла блокировку.
Пока скрипт залочивший файл не отработает - остальные будут стоять на очереди.
flock
3. LEONeso - 27 Июня, 2011 - 08:53:44 - перейти к сообщению
DeepVarvar, я так понял - в таком случае, пока человек не закончит редактирование записи страница не разблокируется? Я хочу учесть возможность человеческого фактора "всё бросить на пол пути и уйти" таким образом, проверка даты - это лучший вариант т.к. если микротайм покажет, что 5 минут уже прошли, тогда данные ему выведутся, тут дело в том, чтобы отдать запрос в бд, получить данные, сверить с доступностью и выдать сообщение или остальные данные из запроса. Всё делается в потоке - по моему достаточно рабочий вариант?
4. DeepVarvar - 27 Июня, 2011 - 09:36:34 - перейти к сообщению
LEONeso не надо забывать что мы всеже имеем дело с веб-приложениями.
Это не локально исполняемые приложения и их файлы.
Единственная синхронизация может быть какраз по дате, но она не очень хороша.
Типа, если кто-то нажал кнопку "редактировать", то в спецполе редактируемого материала нужно будет записать значение куки как ключ "текущего edit-хозяина".
По ней и проверять кто нажимал редактирование.
Так же стоит учесть момент что если "хозяин" отредактировав минут через 10-15 просто нажмет в браузере history.go(-1), передумает сохранять результат, кука не будет валидна для других "хозяев".
Поэтому нужно ставить лимит времени действия записанной в БД куки.
А это ты не угадаешь какое время поставить 5 мин? 20мин? 60???
Нехорошо...
Да и не видел я чтобы где-то так заморачивались разработчики.
Просто лочили и все.
Это не локально исполняемые приложения и их файлы.
Единственная синхронизация может быть какраз по дате, но она не очень хороша.
Типа, если кто-то нажал кнопку "редактировать", то в спецполе редактируемого материала нужно будет записать значение куки как ключ "текущего edit-хозяина".
По ней и проверять кто нажимал редактирование.
Так же стоит учесть момент что если "хозяин" отредактировав минут через 10-15 просто нажмет в браузере history.go(-1), передумает сохранять результат, кука не будет валидна для других "хозяев".
Поэтому нужно ставить лимит времени действия записанной в БД куки.
А это ты не угадаешь какое время поставить 5 мин? 20мин? 60???
Нехорошо...
Да и не видел я чтобы где-то так заморачивались разработчики.
Просто лочили и все.
5. LEONeso - 27 Июня, 2011 - 09:53:27 - перейти к сообщению
DeepVarvar, я наверное упустил самое главное - это отсутствия регистрации и данных о пользователях. Гостевой доступ к функции редактирования данных. В данном случае редактируются данные к изображениям, нажатием на изображение и подгрузкой обработанных данных в фрейм, дальнейшие действия уже идут через фрейм, где имеется форма ввода данных и кнопка для сохранения.
Если учитывать, что изображений на странице может быть несколько, то при нажатии на любое другое изображение, будут отсылаться $_get параметры в фрейм. От сюда и вывод необходимых данных с возможность их редактирования или их создание, в случае отсутствия данных, при сохранении записи, они создаются.
От сюда еще один момент вытекает, спам клик, прогулка по всем или многим изображениям, пользователь, не подозревая о том, что после нажатия идет блокировка доступности редактирования данных на 5 минут, может отнять возможность редактирования данных для других пользователей. Это социальный интрумент, который основа на человеческом доверии к пользователям, но и как любой программист, я придерживаюсь правилу, не доверять пользователям, по этому, входящие данные проходят проверку и чистку от нежелательных символов и т.п.
Если приоткрыть тайну завесы, то это функция внесения ключевых слов для изображения. В дальнейшем - изображение можно найти в поиске по данных словам или словосочетаниям. Естественно, каждое изображение будет проходить модерацию и после неё, редактирование данных, будет невозможно.
Зачем это надо?
- Одному человеку трудно проиндексировать (в данном случае 40000+ изображений), но если нас "толпа" (700+ ежедневных уникальных посетителей), то данная задача вполне может быть реализована.
--
Как думаете, идея стоит свеч ?
Если учитывать, что изображений на странице может быть несколько, то при нажатии на любое другое изображение, будут отсылаться $_get параметры в фрейм. От сюда и вывод необходимых данных с возможность их редактирования или их создание, в случае отсутствия данных, при сохранении записи, они создаются.
От сюда еще один момент вытекает, спам клик, прогулка по всем или многим изображениям, пользователь, не подозревая о том, что после нажатия идет блокировка доступности редактирования данных на 5 минут, может отнять возможность редактирования данных для других пользователей. Это социальный интрумент, который основа на человеческом доверии к пользователям, но и как любой программист, я придерживаюсь правилу, не доверять пользователям, по этому, входящие данные проходят проверку и чистку от нежелательных символов и т.п.
Если приоткрыть тайну завесы, то это функция внесения ключевых слов для изображения. В дальнейшем - изображение можно найти в поиске по данных словам или словосочетаниям. Естественно, каждое изображение будет проходить модерацию и после неё, редактирование данных, будет невозможно.
Зачем это надо?
- Одному человеку трудно проиндексировать (в данном случае 40000+ изображений), но если нас "толпа" (700+ ежедневных уникальных посетителей), то данная задача вполне может быть реализована.
--
Как думаете, идея стоит свеч ?
6. Мелкий - 27 Июня, 2011 - 10:22:34 - перейти к сообщению
LEONeso, лучшее решение, что я видел:
0) у записи сохраняем дату последнего редактирования
1) при открытии записи на редактирование, сохраняем в сессию/невидимое поле дату последнего редактирования
2) при сохранении данных проверяем текущую дату в базе и сохранённую у нас. Если они различаются - выводим пользователю что-то вроде "запись уже редактировалась, возможно вы захотите изменить что-то ещё", то, что написал он, то, что сохранено в базе.
2,5) для удобства пользователя, можно аяксом тыкать нужную запись на предмет её обновления и в случае такового, вывести пользователю всё то же сообщение.
Так мы сразу облегчаем и проблемы с блокировками и проблемы с перезаписью данных человеком, который отошёл на эти 5 минут.
0) у записи сохраняем дату последнего редактирования
1) при открытии записи на редактирование, сохраняем в сессию/невидимое поле дату последнего редактирования
2) при сохранении данных проверяем текущую дату в базе и сохранённую у нас. Если они различаются - выводим пользователю что-то вроде "запись уже редактировалась, возможно вы захотите изменить что-то ещё", то, что написал он, то, что сохранено в базе.
2,5) для удобства пользователя, можно аяксом тыкать нужную запись на предмет её обновления и в случае такового, вывести пользователю всё то же сообщение.
Так мы сразу облегчаем и проблемы с блокировками и проблемы с перезаписью данных человеком, который отошёл на эти 5 минут.
7. LEONeso - 27 Июня, 2011 - 10:37:05 - перейти к сообщению
Мелкий, мне немного не понятная работа сессий, сессия создается на стороне сервера и записывается ключ в кукисах, если куки у пользователя отключены, сверка сессии будет невозможна? и от сюда может случится параллейное редактирование (кто последний тот и сохранит данные).
Если же сессия работает, только на стороне сервера без куки, то как он может определить владельца сессии?
Пример: Когда я создаю запись в кукис, то использую следующий код
Если же сессия работает, только на стороне сервера без куки, то как он может определить владельца сессии?
Пример: Когда я создаю запись в кукис, то использую следующий код
т.е. используя текущую дату я плюсу ровно год, после года, кука удаляется браузером.
Аналогичные действия я хочу сделать с записью даты окончания блокирования доступа к записи. Если пользователь закончит редактирование записью в бд (кнопка "сохранить"), то дата окончания блокировки будет удалена. Следующий запрос к этой записи выведет данные и обновит дату окончания блокировки записи. На всё даётся 5 минут.