Key Points:
A boundary containing a collection of objects with the same usage rules
Context rules include: synchronization, thread affinity, transactions, etc.
Classes are marked with ContextAttribute, which provide the usage rules
Execution system:
On the newobj IL instruction, the EE finds a compatible or creates a new Context for the object
Ensures the rules are enforced when entering and leaving a context
Provides synchronization rules for managed objects
Flexible synchronization model
A context is an ordered sequence of properties that define an environment for the objects resident inside it. Contexts get created during the activation process for objects that are configured to require certain automatic services such synchronization, transactions, just-in-time activation, security etc. Multiple objects can live inside a context.
Below is a brief summary of some of the Context characteristics:
Contexts are a general mechanism that bound a set of objects.
A context is composed from a set of Context properties.
Classes that can be bound to a context are called context-bound classes.
Context-bound objects are referenced directly within their own context and via a proxy when referenced from another context.
Any call from an object in one context to an object in another context will go through a context proxy and be affected by the policy that the combined context properties enforce.
Contexts are created during object activation i.e. a new object is either placed in an existing context or a new one is created for it, but once there, the object stays in its context for life.
A new object's context is generally chosen based on meta-data attributes on the class. This mechanism is extensible via custom attributes. These are known as static context properties, which are compiled into the class meta-data. Dynamic (also known as configuration) context properties can be applied and configured by administrators.
As a general rule, contexts are freed when there are no longer any external references to objects in the context and there are no threads executing in the context.
When context-bound objects access "agile" locations (location accessible from anywhere- like class static variables) that contain context-bound objects, proxy wrapping and unwrapping must be done.
There is one special kind of context property called an AppDomain property. An AppDomain property defines the boundary that contains the set of statics for a program (set of classes). If the same class is loaded into two contexts with different AppDomain properties then two copies of all of its static member variables are created.
Because all context-bound objects can be proxied across contexts, this imposes certain restrictions on how code can manipulate context-bound objects. For example, code cannot access a field on a context-bound object directly. Another example is that non-virtual calls must be made through an indirection and no inlining is allowed (to allow proxies when appropriate). This makes context-bound objects a good bit more expensive than one would like.
Classes, which are not context-bound, are sometimes referred to as agile classes. This should not be confused with agile locations (described below in the location section), although the ideas are parallel. Agile objects are not bound to contexts and they are not proxied across contexts within the same AppDomain. Agile objects are only agile within an AppDomain. Agile objects "live" in the DefaultContext (of which there is one per app-domain). The default context has no non-trivial properties. Any object passes across an AppDomain boundary is considered to be remoted.
Context-bound objects are very appropriate for transaction isolation/ propagation and other features where the cost is acceptable.
Object
Context
[Visual Basic] Public Class Context Implements ISerializable [C#] public class Context : ISerializable [C++] public __gc class Context : public ISerializable [JScript] public class Context implements ISerializable
[To be supplied.]
Namespace: System.Runtime.Remoting
Assembly: mscorlib.dll