2016-06-08 7 views
0

В настоящее время я работаю над системой, которая выполняет вызовы внешней службы и кэширует некоторые данные в коллекции HttpContext.Current.Items для повышения производительности. Данные могут изменяться довольно регулярно, и они чувствительны к пользователю, поэтому мы в настоящее время храним его только на время текущего HttpRequest.Доступ к данным, хранящимся в HttpContext.Current.Items по потокам

Пример:

if (HttpContext.Current.Items[cacheKey] != null) 
{ 
    LogHelper.Debug<ExampleService>("[- CACHED RESULT -] GetUser({0})",() => email); 
    return (ExampleUser)HttpContext.Current.Items[cacheKey]; 
} 

using (var client = new UserServiceClient()) 
{ 
    using (new OperationContextScope(client.InnerChannel)) 
    { 
     LogHelper.Debug<ExampleService>("GetUser({0})",() => email); 
     exampleUser = svc.GetUser(email); 
     HttpContext.Current.Items.Add(cacheKey, exampleUser); 
    } 
} 

В моей местной окружающей среды это ведет себя, как и ожидалось, и в основном, также делает в постановке, где тот же самый поток используется для продолжительности запроса, однако в производстве это не так, и есть все еще несколько вызовов внешней службы в том же запросе. Это видно из журналов, которые показывают, что значение в HttpContext.Current.Items[cacheKey] не возвращается в тех случаях, когда идентификатор потока не соответствует исходному запросу.

Это, я думаю, означает, что мое нынешнее понимание HttpContext.Current.Items неверно и что это не подходящее решение для моих нужд.

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

+0

HttpContext.Current - это поток, как вы уже узнали сами. Если вы хотите использовать HttpContext.Current текущего запроса в каком-то другом потоке - сначала получите ссылку на него в текущем потоке, а затем передайте его этому другому потоку. – Evk

+0

HttpContext.Current.Session - это область, предназначенная для одного пользователя; любой объект, сохраненный в сеансе, будет доступен только для пользователя/сеанса, который его создал. – Eldho

+0

Я понимаю, что использование хранилища сеансов не является отличной идеей из-за использования памяти (это один из многих элементов, которые могут быть сохранены), но также и то, что он не масштабируется, например, если сайт позже переходит в среду балансировки нагрузки? – ProNotion

ответ

0

Одним из вариантов является использование сеанса для хранения ваших данных. К сожалению, он не применим для запросов, специфичных для API (например, мобильное устройство выполняет вызов API-интерфейса сервера). Кроме того, для состояния сеанса сервера требуются все ваши сериализуемые данные (состояние сеанса БД отсутствует).

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

Смежные вопросы