Рекомендации по параллельному сеансу ASP.NET

Question

Пользователь A входит в систему управления билетами, чтобы редактировать содержимое в «SomePage.aspx»

Пользователь B регистрируется через 30 секунд, чтобы отредактировать тот же билет на «SomePage.aspx»

Каковы некоторые из наиболее известных методов (в 3-уровневой архитектуре) для уведомления каждого пользователя о том, что кто-то другой изменяет тот же контент?

Answer 1

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

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

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

Answer 2

Roundup использует (например) оптимистический подход параллелизма: когда вы отправляете свое изменение, вы можете увидеть предупреждение о том, что кто-то внес изменения перед вами, со ссылкой на страницу, показывающую их изменения. Вы можете нажать кнопку «Отправить», чтобы продолжить изменение или изменить значения в форме, а затем отправить.

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

Answer 3

Лучший способ, который я нашел для предотвращения оптимистического параллелизма, - это добавить поле с именем timestamp в базу данных, например: SQLTimeStamp. Это поле содержит уникальное значение для каждой записи в таблице. когда пользователь A запрашивает таблицу для редактирования, сохраните значение sqltimestamp в сеансе. Если пользователь B запрашивает и обновляет ту же запись перед пользователем A, значение метки времени sql изменяется. Если пользователь А теперь пытается сохранить отредактированное значение, сначала проверьте, совпадает ли метка сеанса с текущей меткой времени в базе данных, и если метка времени отличается, подскажите пользователю, кто-то изменил запись.

Это решение, которое я использую для веб-приложения.

Answer 4

Я не очень опытен в этом, но если мне нужно сделать что-то подобное, я бы создал новое поле в базе данных таблицы заявок под названием EditingBy и добавил бы значение по умолчанию '0 .

когда пользователь вызывает TicketID = 897, запрос должен выглядеть следующим образом:

SELECT * FROM Tickets WHERE TicketID = 897; 
UPDATE Tickets SET EditingBy = @UserID WHERE TicketID = 897;

затем в коде вы видите, что если EditingBy больше 0, вы можете предупредить UserB о том, что UserA (вы знаете UserID) редактирует заявку, как SO, когда кто-то публикует ответ, а вы пишете свой, или когда например, вы получаете новый значок.

при подтверждении заявки на обновление вы можете обновить поле обратно до 0.

и имейте в виду, что пользователь может войти в SomePage.aspx и уйти, ничего не делая, для этого javascript onUnload в теге body, который вызовет асинхронный вызов для обновления EdittingBy обратно до 0, будет быть идеей.

надеюсь, что это дает вам представление о том, как это сделать.

Отредактировано: вы всегда можете записать EditingBy в файл XML, если вы не можете редактировать саму базу данных, просто сохраните TicketID и UserID, и вместо того, чтобы находить, если он больше 0, просто проверьте, есть ли TicketID в XML.

Answer 5

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