When a client make a request to WCF, WCF service creates an instance of service to service the client request. After the request completion what will happen of that object we will see here.
Instance Context Mode dictates how long the service instance remain on the server.
There are three instancing modes
In this state is not maintained between request.
Instance Context Mode dictates how long the service instance remain on the server.
There are three instancing modes
Per Call :-
A new instance of service object is created for every request, whether the request is coming from same client or different client. It means service object is destroyed after the completion of request i.e after the response sent to the client.
In this state is not maintained between request.
Per Session :-
A new instance of service object is created for every new client session and that service object maintained during that session.
Per Session :-
A single object serves all request whether they are coming from same client or different client during the lifetime of application.
It can be set using InstancContextMode in service behavior.
[ServiceBehaior(InstanceContextMode = InstanceContextMode.PerCall]
public class LoadService: ISService
{
}
Implications of Per Call
1. Better memory usage as object is freed immediately.
2. No Concurrency
3. No State maintained between call.
4. Performance could be an issue as object is created for every method call
5. Application scalability is better because it service does not hold any resources.
[ServiceBehavior (InstanceContextMode = InstanceContextMode.PerCall)]
public class MathService :IMatchServie
{
int _iVal;
public int IncreamentVal()
{
_iVal =_iVal+1;
return _iVal;
}
}
Client Code
static void main(string[] args)
{
MatchService.MathServiceClient client = new MatchServiceClient()
int iVal = client.IncreamentVal();
Console.WriteLine("Vale after first call "+ iVal);
int iVal = client.IncreamentVal();
Console.WriteLine("Vale after Second call "+ iVal);
}
Output
Value after First call 1
Value after Second call 1
Implications of Per Session
1. State maintained between calls for same client.
2. More memory consumption as service objects remain in memory until the client session timeout. On the other this affect application scalability negatively.
3. Concurrency is an issue multi threaded client.
4. The default session time out is 10 minutes.
[ServiceBehavior (InstanceContextMode = InstanceContextMode.PerSession]
public class MathService :IMatchServie
{
int _iVal;
public int IncreamentVal()
{
_iVal =_iVal+1;
return _iVal;
}
}
Client Code
static void main(string[] args)
{
MatchService.MathServiceClient client = new MatchServiceClient()
int iVal = client.IncreamentVal();
Console.WriteLine("Vale after first call "+ iVal);
int iVal = client.IncreamentVal();
Console.WriteLine("Vale after Second call "+ iVal);
}
Output
Value after First call 1
Value after Second call 2
State is maintained for same client means if you create another client like second console application and call increment method it will give you fresh value.
Which is better Per Call or Per Session
1. Both have different strength and weakness
2.If you prefer object oriented style than persession is better, if you prefer SOA (Service Oriented Architecture Style) than percall is better.
3. Per Session is better for performance and Per is better for scalability.
Does all binding support session?
No, All binding does not support session like basichttp binding does not support session. If a binding does not support session than service behaves like per call. netTcpbinding support session.
How to control the WCF service time out?
You can set the receivetimeout attribute in binding tag. and reset it. by default it is 10 minutes.
What happens when the session timeout reached?
When the session timeout reached the connection to the WCF service closed. And communication channel gets faulted and the client can no longer use the same proxy instance to call method. And on calling an exception throws by WCf service. And the data in service object lost.
How to fix the communication channel in case of faulted state exception?
Using try catch block at client side and re- create the proxy object in catch block in case of Communication exception.
At client side to retrieve session id we use
client = new MathServiceClient()
client.InnerChannel.SessionId
At WCF service to retrieve session id we use
OperationContext.Current.SessionId
client side and WCF server side session id are co related using the reliable session setting at WCF service host, it is defined in binding tag
If reliableSession is disable than both session id will be different otherwise same. By default it is disabled.
<bindings>
<netTcpBinding>
<binding name="netTcpBinding" receiveTimeout="00:00:10">
<reliableSession enabled="true"/>
<binding>
<netTcpBinding>
<binding>
If binding s wsHttpBinding than session id will be same irrespective of relaibleSession means session id will be same even relaibaleSession if disable.
There are three value of session mode
Session Id
To send message from a particular client to a particular service instance on the server, WCF uses session id.
At client side to retrieve session id we use
client = new MathServiceClient()
client.InnerChannel.SessionId
At WCF service to retrieve session id we use
OperationContext.Current.SessionId
client side and WCF server side session id are co related using the reliable session setting at WCF service host, it is defined in binding tag
If reliableSession is disable than both session id will be different otherwise same. By default it is disabled.
<bindings>
<netTcpBinding>
<binding name="netTcpBinding" receiveTimeout="00:00:10">
<reliableSession enabled="true"/>
<binding>
<netTcpBinding>
<binding>
If binding s wsHttpBinding than session id will be same irrespective of relaibleSession means session id will be same even relaibaleSession if disable.
Single :-
In single instance context mode only one object created for all client and for all request.Service object is not destroyed after request completed it remains in memory.
In single context mode session id will be same for a client for all request. session id will be different for two different client.
State is maintained and shared between different request and from different client.
Concurrency can be an issue.
To resolve concurrency we can configure the service to allow a single thread at time.
SessionMode Enumeration
Session mode enumeration is used in service contract to specify whether session is allowed or not not in service
There are three value of session mode
Allowed :-
By default session is allowed in service contract
Not Allowed :-
In this case session is not allowed so service does not support binding that initiate session
Required :-
In this case service contract require a binding that support session.
If session mode is allowed and Instance Context is Single than what will happen?
In that case we use basicHttpBinding that does not support session than service will work as Single ton but without session but session id will be null.
If we use netTcpBinding that support session than service still work as Singleton but with session.
If session mode is required and Instance Context is Single than what will happen?
In that case if we use basicHttpBinding than service will throw error because basicHttpBinding does not support session.
And netTctBinding will work fine with session.
part-42
No comments:
Post a Comment