Как реализовать время ожидания сеанса на стороне веб-сервера? - PullRequest
1 голос
/ 04 апреля 2010

Я видел веб-фреймворк, реализующий таким образом сеанс в памяти. Объект сеанса добавляется в кэш с тайм-аутом. Когда время истекло, сеанс удаляется из кэша автоматически. Чтобы защитить состояние гонки, каждый запрос должен получить блокировку для данного объекта сеанса для продолжения. Каждый запрос "коснется" сеанса в кэше для обновления тайм-аута.

Все выглядит хорошо, пока этот сценарий не обнаружен. Скажем, одна операция занимает больше времени, чем время ожидания. Другой запрос приходит и ожидает блокировки сеанса, которая в настоящее время удерживается долгим запросом. Наконец, долгосрочный запрос закончен, он снимает блокировку. Но, поскольку это уже занимает больше времени, чем время ожидания, объект сеанса уже удален из кэша. Это очевидно, потому что единственный запрос, удерживающий блокировку, не может " коснуться " объекта сеанса в кеше. Второй запрос получает блокировку, но не может получить просроченный объект Session. К сожалению ...

Чтобы устранить эту проблему, второй запрос должен заново создать объект Session. Но это все равно, что выкапывать захороненное мертвое тело из гробницы и пытаться вернуть его к жизни. Это вызывает глючный код.

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

Ответы [ 2 ]

2 голосов
/ 04 апреля 2010

Привет, Морган Чен (жители Гонконга?),

Может ли ваша проблема быть решена с помощью touch -объекта сеансового объекта, когда ваш долгосрочный запрос завершится?

Давайте обсудим решение на примере.При поступлении запроса вы касаетесь сеанса и продлеваете его на 5 минут.Когда запрос заканчивается, вы также касаетесь сеанса и продлеваете его на 1 минуту, прежде чем снимать блокировку.Если результат «запрос на завершение + одна минута» раньше, чем «запрос на начало + 5 минут» , то используйте последний в качестве тайм-аута;в противном случае используйте первое.(Конечно, 5 минут и 1 минута могут быть любыми значениями, которые вам нравятся.)

Интересно, какой «кеш» вы используете.Из вашего описания кажется, что кеш уничтожает объект сеанса "автоматически".Если это так, вы можете touch сеанс с очень большим значением времени ожидания, например, один день , когда поступит запрос.Когда запрос заканчивается, вы повторно touch используете разумное значение, скажем, 5 минут .Или, чтобы быть умнее , используйте значение: (5 minutes - request_time > 1 minute) ? (5 minutes - request_time) : 1 minute), где request_time - время, потраченное на запрос.

Надеюсь, это поможет.

Аска Кенджи

(из Гонконга)

1 голос
/ 04 апреля 2010

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

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