Безопасна ли многопотоковая реализация ASP.NET Core Session? - PullRequest
Новая
       30

Безопасна ли многопотоковая реализация ASP.NET Core Session?

0 голосов
/ 24 мая 2019

Я знаю, что есть аналогичный вопрос , но это касается ASP.NET, а не ASP.NET Core.Ответы 7-9 лет, и смешивание разговоров об ASP.NET и ASP.NET Core может быть не очень хорошей идеей.

Что я имею в виду поточно-ориентированный в этом случае:

Безопасно ли использовать методы чтения-записи (например, Set(...)) Session (доступ осуществляется через HttpContext, доступ к которому осуществляется через введенный IHttpContextAccessor) в нескольких запросах, принадлежащих одному сеансу?

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

Я взглянул на DistributedSession исходный код , который, по-видимому, является значением по умолчанию (мой сеанс в отладчике, доступ к которому описан выше, является экземпляром DistributedSession) и никаких следов какой-либо сериализации или других методов, таких как блокировки ... дажезакрытый _store член является чистым Dictionary ...

Как этот поток может быть безопасным для одновременного использования модификации?Чего мне не хватает?

1 Ответ

2 голосов
/ 24 мая 2019

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

Сеанс использует словарь в качестве основного источника данных, который также является локальным для объекта DistributedSession.Когда сеанс инициализируется, сеанс инициализирует словарь _store лениво при обращении к сеансу путем десериализации сохраненных данных из кэша. Это выглядит так : 

var data = _cache.Get(_sessionKey);
if (data != null)
{
    Deserialize(new MemoryStream(data));
}

Таким образом, доступ к _cache здесь представляет собой одну операцию.То же самое относится и к записи в кэш .

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

. Для одновременных запросов все это означает, что вы не должны ожидать, что один запрос окажет непосредственное влияние на сеансдругой запрос.Сеансы обычно десериализуются только один раз, поэтому обновления, которые происходят во время запроса (другими запросами), не отображаются.

...