Предотвращение использования пользователями одной и той же строки

У меня есть веб-приложение на работе, похожее на систему работы с билетами. Некоторые пользователи вводят новые проблемы. Другие работники выбирают и решают проблемы. Все данные хранятся на сервере MS SQL 2005.

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

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

Проблема в том, что часть AJAX этого отправляет слишком много обновлений (это то, что я предполагаю), и это влияет на производительность страницы и базы данных. Кроме того, обновления не выполняются каждую секунду. Я считаю таймер ненадежным при работе над запуском хранимых процедур.

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

Спасибо,

Ответ 1

Две проблемы могут помочь смягчить вашу проблему.

Во-первых, уведомление после выбора, которое было принято, необходимо независимо от вашего временного интервала обновления ajax. Даже проверка каждой секунды не означает, что два человека не могут щелкнуть один и тот же случай по тому, что они воспринимают как одно и то же время. В таких случаях один из пользователей должен быть уведомлен о том, что их выбор недействителен, даже если он оказался действительным при его выборе. Это уведомление не нуждается в разработке; поддержание легкого, полезного тона может улучшить восприятие пользователя даже в свете разочарования. И если вы идентифицируете пользователя, который уже выбрал эту запись, это не только поможет вашим координаторам в будущем, но и отвлечет внимание вашей программы на пользователя, который запустил сочный случай. (действительно, менеджменту может нравиться давать вашим пользователям случайное столкновение, поскольку оно будет мотивировать их быстрее выбирать случаи)

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

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

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

Ответ 2

Поместите поле метки времени блокировки в строке базы данных. Напишите хранимую процедуру proc, которая вернет true или false, если истечение времени ожидания превышает установленное время. Установите сеансы в своем веб-приложении, чтобы истечь в одно и то же время, минуту или две. Когда пользователь выбирает строку, они попадают в сохраненный процесс, который помогает приложению решить, разрешить ли пользователю изменять его.

Надеюсь, что это имеет смысл....

Ответ 3

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

Ответ 4

Вы пытались увеличить время между обновлениями. Я бы ожидал, что один раз за 30 секунд будет достаточно. 40 запросов/минута - это намного меньше нагрузки, чем 1200/минута. Ваши пользователи могут даже не заметить разницу.

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

Ответ 5

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

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

Ответ 6

Мне не хватает этой проблемы, особенно после того, как вы упомянули, что вы уже отмечаете билеты в процессе/поддерживаете и имеете временную метку/версию элемента.

Не достаточно:

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

Когда элементы извлекаются в 1, вы включаете метку времени/версию. Когда 2 происходит, вы используете оптимистический подход concurrency, чтобы убедиться, что, если 2 человека попытаются обновить билет, в то же время только первый будет успешным.

Что произойдет, так это то, что для второго человека обновление... где... timestamp = @timestamp не найдет никаких записей для обновления, и вы сообщите, что билет уже сделан.

Если вы хотите, вы можете построить сверху выше, чтобы обновить интерфейс, когда будут схвачены билеты. Это может быть сделано путем полного обновления текущей страницы билетов после x времени (возможно, оповещения/запроса пользователя) или даже путем извлечения списка билетов, измененных для страницы билетов, показываемых с помощью ajax. У вас все еще есть более ранние шаги, поскольку это изменение просто удобство для пользователей.