Использование CallContext для хранения HttpContext для WCF - PullRequest
0 голосов
/ 13 сентября 2018

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

Моя первоначальная проблема заключается в том, что после первого await, HttpContext.Current становится нулевым и, следовательно, вторая операция завершается неудачно.Я часами искал в Google и проверял все, что нашел ... Пользовательский контекст синхронизации, appSettings в web.config, таргетинг на .NET 4.5, включение совместимости с ASP.NET, но ничего не получалось.

Затем я обнаружил этот пост , говорящий о CallContext.По сути, идея заключается в том, чтобы хранить HttpContext.Current в CallContext.Я проверил и да, это сработало.Однако, поскольку я точно не знал, что такое CallContext, я читал об этом.

Я не уверен, что действительно все правильно понял, но после прочтения у меня возникло беспокойство.Я могу ошибаться, но кажется, что нет никакой гарантии, что поток, восстановленный после выполнения асинхронного вызова, совпадает с исходным потоком.Проблема в том, что я храню несколько значений в HttpContext, и я боюсь, что первый метод будет выполняться со значениями пользователя A, а затем, когда асинхронный вызов будет выполнен, второй метод будет выполняться со значениями пользователя B (какHttpContext не будет таким же).

Я думаю, у людей будет искушение сказать мне, чтобы я сохранял только эти значения в CallContext, но я создал целую архитектуру, прежде чем столкнулся с проблемой WCF.поэтому я не хотел бы полностью его пересматривать, поэтому CallContext пригодится, поскольку изменения незначительны.

Может кто-нибудь сказать мне, верна ли моя теория или нет?

Ответы [ 2 ]

0 голосов
/ 14 сентября 2018

WCF - это несколько целостная SOA-архитектура, предоставленная вам из коробки с поддержкой нескольких протоколов, и все настраивается, кроме того, вы можете расширять и настраивать все.Таким образом, получить все очень сложно. Основы:

Три типа WCF параллелизм :

Single : один запрос имеет доступ кОбъект службы WCF в данный момент времени.

Несколько : в этом сценарии объект службы WCF может обрабатывать несколько запросов в любой данный момент времени.

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

Кажется достаточно простым, но подождите, он имеет экземпляры режимов , которые отличаются от параллелизма :

- за вызов Новый InstanceContext (и, следовательно, объект службы) создается для каждого запроса клиента.

- За сеанс Новый InstanceContext (и, следовательно, объект службы) создается длякаждый новый клиентский сеанс и поддерживается в течение всего времени этого сеанса (для этого требуется привязка, поддерживающая сеансы).

- один экземпляр : один InstanceContext (и, следовательно, объект службы) обрабатывает весь клиентзапросы на время жизни приложения.

Режим экземпляра по умолчанию - на сеанс, а режим параллелизма по умолчанию - один * 10.41 *

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

Подробнее см .: MSDN

0 голосов
/ 14 сентября 2018

Вам следует изменить свои услуги, чтобы они не зависели от HttpContext.Current. Предпочтительно, чтобы вообще не зависеть от HttpContext.

HttpContext.Current является эквивалентом потока пользовательского интерфейса на стороне сервера. Только не используйте его в коде, который не должен зависеть от него.

...