There are three types of instance activation ways
- Per-Call
- Per-Session
- Single
those three three types are similar to .Net Remoting’s instance activation ways,which is SingleCall(Per-call in WCF),CAO(Per-Session) and Singleton(Single). we can set the instance activation ways by seting ServiceBehavior Attribute.
Per-Call
to configure a service type as per-call servie, you apply the ServiceBehavior attribute with InstanceContextMode property set to InstanceContextMode.PerCall,when the service type is configured for per-call activation, which means every client request get a new service instance, all requests share nothing.
the benifits of PerCall services,the instance may hold some expensive resources,with the Per-Call service,the client can’t hold the limited resource so long, they dispose of the resource after the request is finished ,the drawbacks of PerCall services are about concurrency, an instance of a per-call service is created just before every method call and is destroyed immediately after each call. If the service has implemented the IDisposeable interface, wcf will automaticaly call the dispose function to do some required clean up.the next request can excute untill the finish of last request’s dispose. so don’t do some operations which takes to long to complete in the Dispose function while the service is configured as Per-call service and the service support the session(here,support session doesn't mean that the service is a per-session service,just support).
The default configuration of InstanceContextMode is PerCall.
Per-Session
to configure service type as per-Serssion service,it is more complex than per-call, three elements are required, which are service behavior(SessionMode perpoty of ServiceContract), binding(the binding must support the session) and the contract,so as to implement successful per-session service, you must apply the ServiceBehavior attribute with InstanceContextMode property set to InstanceContextMode.PerSession and apply the ServiceContract attribute with SessionMode property set to SessionMode.Allowed or SessionMode.Required and with service binding which supports the transport-level session, only those three conditions can make a service behave as a per-session service.
as a per-session service, the instance of the same client share the same information on the server. Every session share a session between the service and client,the session will be destroyed while the client is shut down and created just before the client’s first call.
The default configuration of SessionMode is Allowed.if the SessionMode is set to Required but with a binding which does't not support transport level session,there will be a running time exception throwed.
The SessionMode which is a property of ContractService is designed for Contract while the InstanceContextMode which is a property of ServiceBehavior for service
The bindings which support session service are limited, TCP,IPC and WS with security or reliablity.
Single
just like Per-call service ,to configure a service as single service,only we can do is to set the InstanceContextMode to Single.Single service is the ultimate sharable service.all client get connected to the same single instance,they share everything of server, no matter which endpoint the clients connect to.the instance is created immediately after the host is created and is destroyed after host is shut down. because of the features of the single service, only one client at a time can access the service, this may degrade the throughput. if a operation can take one-tenth of a second,10 requests must need 1 second. so if there are many clients,the performance of system will be badly affected.
the single service should be avoided, we should find other ways to share the inforomation instead of single service.
How do we choose those instance types.there are no hard and fast rules. as a developer we must make many trade-offs between the performance and scalability and make the suitable choice.