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

Question

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

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

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

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

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

Спасибо

Answer 1

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

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

Answer 2

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

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

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

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

С помощью этих шаблонов смягчения вы, вероятно, обнаружите, что можете безопасно сократить сроки выполнения запросов AJAX, не влияя на взаимодействие с пользователем. А благодаря полезной регистрации вы получите уверенность в том, что любые изменения, которые вы установили, на самом деле работают (или не & mdash; это может быть даже более полезно знать).

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Разве недостаточно:

1. Пользователь просматривает заявки и видит список доступных заявок, т. Е. Исключая те, которые находятся в БД как в процессе выполнения. Если вы хотите, чтобы пользователи также видели билеты в процессе, вы четко указываете их в статусе заявки и отключаете опцию, чтобы принять их.
2. Пользователь может явно или неявно пометить билет как выполняемый, открыв билет (зависит от опыта пользователя / того, как он был представлен пользователям).
3. Пользователь явно переводит заявку в другой статус, т. Е. Заполнен, недействителен, ожидает ответа и т. Д.

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

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

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