Использование CallContext для хранения HttpContext для WCF
В настоящее время у меня есть служба 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 ответа
WCF - это несколько целостная архитектура SOA, предоставленная вам из коробки с поддержкой нескольких протоколов, и все настраивается, кроме того, вы можете расширять и настраивать все. Так что получить все очень сложно. Просто основы:
Три типа параллелизма WCF:
Single: один запрос имеет доступ к объекту службы WCF в данный момент времени.
Несколько: В этом сценарии объект службы WCF может обрабатывать несколько запросов в любой момент времени.
Повторно входящий: единственный поток запроса имеет доступ к объекту службы WCF, но поток может выйти из службы WCF для вызова другой службы WCF или также может вызвать клиента WCF через обратный вызов и повторно войти без тупика.
Кажется достаточно простым, но подождите, пока у него есть режимы экземпляров, которые отличаются от параллелизма:
- За вызов. Новый InstanceContext (и, следовательно, объект службы) создается для каждого запроса клиента.
- Для каждого сеанса Новый InstanceContext (и, следовательно, объект службы) создается для каждого нового клиентского сеанса и поддерживается в течение всего времени этого сеанса (для этого требуется привязка, поддерживающая сеансы).
- Один экземпляр: один InstanceContext (и, следовательно, объект службы) обрабатывает все клиентские запросы за время существования приложения.
Режим экземпляра по умолчанию - на сеанс, а режим параллелизма по умолчанию - один
это означает, что для службы WCF до тех пор, пока вы не измените свою службу, имеет только один контекст экземпляра, разрешено иметь не более одного потока, обрабатывающего сообщения в контексте экземпляра одновременно. Другие потоки, желающие использовать тот же контекст экземпляра, должны блокироваться, пока исходный поток не выйдет из контекста экземпляра.
То, чего вы боитесь, кажется невозможным, пока вы не внесете изменения в код и не захотите, чтобы это произошло.
Для более подробной информации обратитесь к: MSDN
Вам следует изменить свои услуги, чтобы они не зависели от HttpContext.Current, Желательно, чтобы не зависеть от HttpContext совсем.
HttpContext.Current является эквивалентом потока пользовательского интерфейса на стороне сервера. Только не используйте его в коде, который не должен зависеть от него.