CallContext переносит вперед предыдущие данные, которые были установлены

Question

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

Предположим, у меня есть простой API, который при постановке в очередь устанавливает одну запись данных в CallContext, используя:

// entry to the API execution within OnStartProcessingRequest method of DataService
if(CallContext.LogicalGetData("data") != null)
    CallContext.LogicalSetData("data", someValue)
print("data " + CallContext.LogicalGetData("data"))

Когда я вижу журналы после некоторых запросов API, я вижу похожие журналы.

| нить | журнал |
| 237 | данные 23 |
| 145 | данные 19 |
| 872 | данные 78 |
| 237 | данные 23 |

Меня беспокоит, почему нить с идентификатором 237 забирает старые данные? то есть 23
Я уверен, что элемент управления не входит в блок кода LogicalSetData, поскольку в нем уже есть данные.

Я не уверен, почему это происходит? Кто-нибудь может мне с этим помочь?

Сервис является сервисом данных WCF. Звонок осуществляется от клиента REST почтальона.

Answer 1

Рассмотреть возможность перехода на OperationContext так как это встроенный и естественный контекст для хранения данных по конкретному запросу.
CallContext.GetData получит данные, которые были установлены через SetData из того же потока. Данные, сохраненные с помощью CallContext.LogicalSetData, считаются локальными "логическими нитями". То есть любые данные, которые хранятся через CallContext.LogicalSetData, будут "перетекать" в любые дочерние потоки. Если вы вызываете CallContext.LogicalGetData в том же потоке или любых дочерних потоках, вы получите данные, которые были сохранены при вызове этого потока (или родительского потока), в CallContext.LogicalSetData. Лучшее описание в этой замечательной статье.
Я не смог найти никакой информации, что CallContext должен быть чистым при каждом запуске запроса, однако я нашел эту старую статью, описывающую пользовательскую реализацию ICallContextInitializer. Это говорит:

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