Analysis of WCF Technology 23: Service Instance how life cycle control [previous]

The purpose of the service invocation is embodied in the consumption of a service function, and the implementation of the function is defined in the corresponding service type. Regardless of the complexity of the process of processing service invocation requests by the WCF service-side framework, the implementation of the activation and operation methods of the service instance is ultimately implemented. Instance management in WCF (Instance Management) is designed to address the activation of service instances and control of service instance lifecycles.

The purpose of a session is to maintain the state between multiple service invocations from the same client (service proxy). From the point of view of message exchange, a session uses the message recognition mechanism to determine the message source that invokes a service, thereby associating all messages from the same client. Therefore, the session implements the Message Association (correlation).

Instance session is a very important two features of WCF, they are both relatively independent and mutually restrictive. The combination of the instance pattern and the level of support for the session will allow the final service to behave differently. The rational use of instance management and session is crucial for improving and improving the scalability (scalability), performance (performance), throughput (throughput) of WCF service applications. The service instance object is not isolated, but is encapsulated into a special instance context (InstanceContext) object, which is mentioned in the instance context.

One, instance context (InstanceContext)

The instance context is the encapsulation of the service instance and is the basis of the WCF Management Service instance lifecycle. Let's put aside WCF to briefly describe how the common language runtime (CLR) is performing the lifecycle of managed objects in a managed environment. In a managed application, when we create a managed object in a different way, such as through the new keyword, reflection, or deserialization, the CLR creates a memory space for the object in the managed heap. The essence of an object is that it is stored in the memory of a block of data, and the life cycle of the object is terminated when the corresponding memory is reclaimed. For the CLR, the component responsible for reclaiming the managed heap (where the GC heap is primarily referred to) is the garbage collector (GC), which holds the power of the managed object and determines the lifecycle of the managed object.

When GC is garbage collected, the "unwanted" object is marked as a garbage object, and then the garbage object is cleaned up. The GC's identification mechanism for "useless" objects is simple: Determine if the object is referenced by "root (Root)." Here, "Root" is a group of objects that are currently being used, or may later be used, and generally include such objects: static fields of types or current method parameters and local variables, CPU registers, and so on.

Therefore, isolated objects will be difficult to escape by GC recovery of Doom. Conversely, if you want an object to reside in memory, the only way we can do that is through a "root" reference to that object. The example management described in this chapter, is the management of the service instance lifecycle, where the service instance is created, alive, and extinct in the way we want, so our only way is to prevent it from being recycled by the GC when it is expected to survive by a "root" reference. , even "root" removal when you want the service instance to be reclaimed, so that the GC can recycle it. The instance context (InstanceContext) described in this section acts as a "root" role.

When it comes to the instance context, it is not unfamiliar to the reader, because in a WCF two-way (Duplex) communication we encapsulate the callback object through the instance context. In WCF, the instance context is used not only for encapsulation of callback objects, but also for the encapsulation of real service instances. In fact, the bidirectional communication of WCF can be understood as a kind of peer-to-peer communication, the two sides of the communication are equal participants, there is no strict server and client, or the two sides of the communication play the role of service and customer alternately. The client's normal invocation of the server-side operation is a service invocation, and the server-side callback client operation can also be viewed as a service invocation. Therefore, encapsulating the callback object and the service instance through the instance context is essentially consistent.

The encapsulation of the instance context to the service instance is generally illustrated by figure 1 . A WCF service is hosted through a ServiceHost and adds one or more endpoints. For a service invocation request received, if the corresponding instance context exists, it gets the service instance to process the service request, otherwise the service instance is created and encapsulated by the instance context, then the service request is processed by the instance context.

Figure 1 Encapsulation of the instance context on the service instance

The

Instance context is represented by type System.ServiceModel.InstanceContext. InstanceContext inherits from Communicationobject and implements the Iextensibleobject<instancecontext> interface. The definition of InstanceContext is as shown in the following code:

 1:public Sealed class Instancecontext:communicationobject, Iextensibleobject<instancecontext> 
 2: {   
 3://other member 
 4:public InstanceContext (object implementation); 
 5:public InstanceContext (servicehostbase host); 
 6:public InstanceContext (servicehostbase Host, object implementation);   
 7: 
 8:public object Getserviceinstance (); 
 9:public Object getserviceinstance (Message message); 
 10:public void Releaseserviceinstance (); 
 One: 
 12:public iextensioncollection<instancecontext> Extensions {get;} 
 13:public servicehostbase Host {get;} 
 14:public icollection<ichannel> incomingchannels {get;} 
 15:public icollection<ichannel> outgoingchannels {get;} 
 16:public SynchronizationContext SynchronizationContext {get; set;} 
:} 

InstanceContext has three constructors that accept ServiceHostBase objects and concrete instance objects as their input parameters. Acquisition and release of Getserviceinstance and releaseserviceinstance User Service instances. Incomingchannels and Outgoingchannels represent a collection of stack and stack channels. The SynchronizationContext property allows you to set or get a synchronization context for an asynchronous operation, such as a service operation that requires a control that operates on a Windows Form under a non-UI thread. You will need a synchronization context (SynchronizationContext) based on the UI thread.