Call chain. The state bag is passed down the call chain. The call context provides a set of properties that are carried with the execution code path. Entries can be added to the Call Context as it travels down and back up the execution code path.
Context Switch. The state bag is passed across context boundaries. As a call flows from context to context, the call context is propagated.
AppDomain Switch. The state bag is passed across application domain boundaries. Cloned at AppDomain boundary.
The Call Context is passed in the IMessage as it flows between Contexts and AppDomains. The entry in the message is named “__CallContext”. Message sinks can add and lookup entries in the __CallContext as passes through the message sink chain.
Slots. The Call Context provides data slots for the call path. The data slots are unique per call path i.e. the state is not shared across call paths. The slots are named. The name is used to access the data slot. The slot can be explicitly freed using the name.
“Contextify” System.Delegate.BindToContext. Specifically, the content of the state bag is propagated from System.Delegate.BindToContext() call to the Invoke call.
This class exposes the API for the users of call context. All methods in CallContext are static and operate upon the call context in the Thread.
NOTE: CallContext is a specialized form of something that behaves like TLS for method calls. However, since the call objects may get serialized and deserialized along the path, it is tough to guarantee identity preservation.
public sealed class CallContext { public static Object GetData(String name); public static void SetData(String name, Object data); public static void FreeNamedDataSlot(String name); }
Retrieve an object by name from the CallContext.
Store an object using a name in the CallContext.
Explicitly frees a named data slot.