Czy CallContext może polegać na całej próbie, używając interfejsu API asp.net Web?Czy mogę polegać na CallContext przy użyciu Web API?
Przeczytałem decade-old blog post i nie jestem pewien, czy nadal ma zastosowanie (na pytanie there).
Zakładając, że wątek-agility wskoczy, jeśli ustawię dane w filtrze globalnym, czy można bezpiecznie założyć, że będzie tam przez cały czas żądania?
Utracisz CallContext, jeśli ASP.Net zmieni wątki. W modelu asynchronicznym program planujący zadania asp.net zajmie się łączeniem wywołań asynchronicznych z powrotem do wątku żądania z tym samym HttpContext, ale niekoniecznie tym samym wątkiem.
Przykład: Zgłoszenie rozpoczyna się, a następnie następuje asynchroniczne oczekiwanie na powolny IO przed powrotem - podczas oczekiwania na wolne IO nie ma powodu, aby twój wątek z prośbą nie siedział, nic nie robiąc, aby uzyskać użyte do innego żądania.
ASP.Net jest wielkim ćwiczeniem Thread Agility (Google it), a tam jest również doskonałym dyskusja na ten temat tutaj: CallContext vs ThreadStatic vs HttpContext
CallContext.LogicalSetData i .LogicalGetData powinny działać asynchronicznie. – imukai
@imukai 'CallContext' został zaprojektowany do zdalnego zarządzania, i masz rację - powinien działać na asynchronizację, ale na kim jest słowo? Został zaprojektowany, zanim jeszcze istniała Async. Nigdzie nie udokumentowano tego, co mogłem znaleźć; jedyne informacje, jakie mam, to czytanie innych wątków ludzi dyskutujących i nikt nie wydaje się zgadzać na zachowanie 'CallContext' wewnątrz asp.net. Znacznie lepiej jest użyć 'AsyncLocal', ponieważ został zaprojektowany do tego celu i * jest * udokumentowany. – caesay
Ja testowałem z CallContext.LogicalSetData i kontrolera asynchronicznym (aby przełączyć wątki przed i po) i wygląda na to, że działa dobrze. Jest to jednak dość złożony temat i trudno jest się upewnić, wykonując proste testy. – Evk