Arun Manglick - Technical View: Instancing

Instancing –

· Controls the way the Service Object are allocated to the Request Object.

· Three Modes

· InstanceContextMode.PerCall

· InstanceContextMode.PerSession (Default)

· InstanceContextMode.Single

InstanceContextMode.PerCall

· A new Service Instance is created for each call, even if the same client issues the call.


	Fig:1

· No State is mainitained between calls.

· Concurrency is not concenred - Since new service object is assigned for each call.

· Concurrency is concenred - For resources like Cache, shared by each Service Object, still requires protection for Concurrent access. See Below.

Look at below figures.

Service Operations still construct the Business & Data Access Objects to complete their work.

These Business & Data Access Objects, usually belongs to each Service object. Thus released with the completion of each service operation. (Fig 2)

Here even being Per Call, this does not preclude from sharing business objects or cached data across service operations. (Fig 3 & 4)

These scenarios have the possibility of Concurrency.

Fig:2 Seperate Business Objects for each Service Object – No Concurrency Issue	Fig:3 Sharing Business Objects for each Service Object - Concurrency Issue	Fig:4 Sharing Cached between Service Objects - Concurrency Issue

InstanceContextMode.PerSession

· A new Service Instance is created for each client. i.e.

· A new Service Instance is created for the first call from the client proxy, and kept alive for subsequent calls from the same client proxy.

Note: If the client is inactive beyond the Session Timeouts (Default – 10 mins), the Service Instance is disposed.

	Fig:5

Look at below figures.

Maintain State at Business Object - Since each client call gets the same Service Instance for the session duration, the Service Instance can hold references to State-Aware Business Objects. (Fig 6)

Maintain State at Service Object – Here the idea is to maintain State Information in the Service Object, while allowing request to construct its own business object. (Fig 7).

Fig:6 State Aware Business Objects	Fig:7 State Un-Aware Business Objects

InstanceContextMode.Single

· A new Service Instance is created and used for all the calls from all the clients.

	Fig:8 Business Object shared by all request

            Since a singleton service object is shared across all the client request, it is really upto the Singleton to determine how its state is managed across those requests.
          By definition any references to business objects held by the singleton will be shared by all requests. (Fig 8)

Look at below figures.

Per Session Business Object – Fig 9

· If the binding supports sessions and the 'Session Mode = Required/Allowed', a session is created for each client.

· In this case. though the same Singleton object handles each request, a session identifier is assigned for each client to distinguish them from each other.

· It is up to you to use this session identifier to allocate state to each client.

e.g.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]

public class SingletonService : ISingletonService, IDisposable

{

Dictionary<string, int> m_counters = new Dictionary<string, int>();

public void IncrementCounter()

{

if (!m_counters.ContainsKey(OperationContext.Current.SessionId))

m_counters.Add(OperationContext.Current.SessionId, 0);

m_counters[OperationContext.Current.SessionId]++;

}

Ignoring State – Fig 10

· Singleton scenario can also choose not to track sessions.

· In this case, though all the requests will funnel thru the Singleton, each operation will constuct its own business objects.

· In some aspects this removes the value of having a Singelton. So it is an unlikely scenario – As Singletons are usually chosen because there is a need to share some state between clients.