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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Для шаблонов такого типа вы должны изучить Использование таблиц в качестве очередей .

Answer 3

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

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