ASP.NET-сессии и параллелизм

Question

У меня есть устаревшее приложение ASP.NET, в котором есть некоторые проблемы, связанные с сеансом/параллелизмом, и несогласованность.

Ищу лучший способ сделать редизайн/

Это сценарий A. Несколько пользователей могут войти на сайт и доступ/изменить детали билета в. Однако, если пользователь уже в процессе изменения рабочего процесса ... TicketId, UserId хранятся в БД с отметкой времени.

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

C. Если начальный/заблокированный пользователь выполняет «Вывод», блокировка освобождается в БД. Теперь последующий пользователь может получить доступ без сбоев.

Все это прекрасно ... но если начальный пользователь ... вместо «выходить» ... просто закрывает окно браузера .. приложение все еще остается заблокированным.

Как этого избежать? Каков наилучший дизайн в этом сценарии?

Answer 1

Это называется пезимический параллелизм. Вы можете обрабатывать событие SessionEnd (но только если вы используете сеанс InProc) и освободить блокировку билета. Проблема в том, что сеанс по умолчанию истекает через 20 минут. Поэтому, если вы действительно хотите использовать pesimistic параллелизм, вы должны сделать сеанс как можно короче, но это может повлиять на текущий пользователь - сессия может быть потеряна во время его работы в браузере. Чтобы избежать этого, выполните javascript-таймер и некоторую операцию javascript/ajax ping, которая сохранит ваш сеанс, пока пользователь откроет браузер. Если он закроет браузер, не выпуская сеанс, истечет срок его действия. Существует еще недостаток: если ваш пользователь закроет браузер и через некоторое время откроет новый, все его данные сеанса будут потеряны.

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

Answer 2

Мне кажется, что самое лучшее, что вы могли бы сделать, это построить тайм-аут сеанса make-shift. Когда билет становится заблокированным, вы можете штамповать его со временем его блокировки. Всякий раз, когда другой человек пытается получить доступ к этому билету, вы можете проверить, не видно, только если он был заблокирован, но также и когда он был заблокирован, и если он был заблокирован больше, чем о ... скажем, 5 часов назад, вы можете разблокировать билет, но потерять предыдущие изменения пользователей.

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

Answer 3

К сожалению, у вас нет другого выбора просто тайм-аут а «блокировки ». Поскольку связь между браузером и сервером не является надежной/надежной, вы не можете обнаружить все пути, что пользователь отказался от работы, включая внезапное закрытие браузера, сброс модема клиентского широкополосного модема, отказ сети или прерывания питания. Таким образом, все, что вы можете сделать, это иметь «блокировки», помещенные на предметы, имеют тайм-аут. Если пользователь не выполнит работу, скажем, 30 минут, элемент возвращается в пул доступных элементов. Этот «возврат» не должен быть активной операцией, он может быть неявным: действие «блокировки» или резервирования рабочего элемента добавляет метку времени UTCNOW() + 30 минут. Любой элемент с меткой времени в минута хорош для захватов и считается разблокированным (то есть пользователь не закончил работу над ним в течение 30 минут).Если пользователь возвращается с обеда и пытается завершить работу после 45 минут, вы отказываетесь от отправки и попросите его начать заново. Если пользователь периодически обновляет работу (скажем, что он экономит каждые 10 минут), возможно, он может продлить «блокировку» на новый 30-минутный период.

Для таких моделей вы должны изучить Using Tables as Queues.