Как настроить блокировку, которая автоматически отключится, если не получит сигнал поддержания активности? - PullRequest
0 голосов
/ 29 декабря 2010

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

Как только пользователь покинет эту страницу, я бы хотел разблокировать ресурс.

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

Например, через 30 секунд после обновления с клиентской стороны разблокируйте ресурс.

Мой основной вопрос, какой уловки я могу использовать для этого?Насколько я понимаю, я не могу просто создать поток в JSF, потому что он будет неуправляемым.

Я уверен, что другие люди делают такие вещи, что правильно использовать?

Спасибо, Грей

1 Ответ

1 голос
/ 29 декабря 2010

Как правильно задал вопрос BalusC, большой вопрос в том, на каком уровне детализации вы хотели бы сделать эту блокировку? Для каждого вошедшего в систему пользователя, для всех пользователей, или, возможно, вы могли бы избежать блокировки по запросу?

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

В последнем случае, возможно, будет работать следующая схема:

  1. В области приложения определите глобальную параллельную карту.
  2. Ключи карты представляют ресурсы, которые вы хотите защитить.
  3. Значения карты - это пользовательская структура, которая содержит блокировку чтения-записи (например, ReentrantReadWriteLock), токен и отметку времени.
  4. В области применения также существует одна глобальная блокировка (например, ReentrantLock)
  5. Код в запросе сначала захватывает глобальную блокировку и быстро проверяет, есть ли запись на карте.
  6. Если запись есть, она берется, в противном случае она создается. Время создания должно быть очень коротким. Глобальная блокировка быстро снимается.
  7. Если запись была новой, она блокируется с помощью блокировки записи, и создаются новый токен и отметка времени.
  8. Если запись не была новой, она блокируется с помощью блокировки чтения
  9. если код имеет тот же токен, он может пойти дальше и получить доступ к защищенному ресурсу, в противном случае он проверяет метку времени.
  10. Если отметка времени истекла, она пытается получить блокировку записи.
  11. Время блокировки записи истекло. Когда наступает тайм-аут, сдавайтесь и сообщайте что-нибудь клиенту. В противном случае создаются новый токен и метка времени.

Это всего лишь общая идея. В приложении Java EE, которое я собираю, я использовал нечто подобное (хотя и не совсем то же самое), и оно работало довольно хорошо.

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

...