Percall InstanceContextMode WCF Service Behavior
I have a WCF Service exposing a ServiceContract with basicHttpBinding, so from my understanding InstanceContextMode will be set to PerCall (since basicHttpBinding doesn't support sessions) and ConcurrenyMode will be set to Single.
The client of this WCF is a Windows service that invokes 4 different operations on the service at the same time, there are several static variables in the service we used for the singleton class. We ran into an issue where the wrong value is passed to some of the DB stored procedures.
In PerCall InstanceContextMode and Single concurrency, I understand that a new instacne service is created for every call, and so I think that even if there are multiple singleton classes (we didn't make them thread safe) in the service implementation and static variables all objects will be destroyed, but we observe the launch of the SQL profiler, which, according to the old value, receives the transferred DB.
We wrote our WCF service code as a 3-tier architecture, I mean ServiceClass, BusinessLogicLayer and DataAccessLayer, with PerCall set as instanceContextMode when we say that the service instance is destroyed after the client request completes, does that mean we are destroying the whole object in the ServiceClass. BusinessLogicLayer and DataAccessLayer?
Help me understand what could be wrong
source to share
InstanceContextMode PerCall means a new class is instantiated for each call. Static variables in your AppDomain will not be reset. They will remain in between service calls until your AppPool is redesigned.
Remove all static including singletons from your code. Either way, they never belonged to your architecture.
source to share
Many WCF requests use the same AppDomain. Static variables are relative to AppDomain. WCF does nothing for these variables (in fact, it can't even detect that they exist ). You are responsible for maintaining them.
WCF does not destroy any of your objects, because WCF does not understand what they mean and does not know that they exist .
The settings you specified are specific to the service object.
My usual advice regarding server stateful applications. Here you are working under bad practices. You need to ensure thread safety. In case the workflow ends (deployment, automatic restart, server reboot, application error, process failure, power loss, hardware failure, ...) your data is lost.
source to share
Although it is limited in any way, static variables should be protected for thread safety as a best practice. Static variables will not be destroyed until the service is stopped / application restarted.
Using static variables on data, changes to which are not recommended for distributed web farms because they are not fail safe.
Visual Studio 2012 and up comes with a memory profiler. But a simple thing can be done by using a counter in object constructors (testing only), which can determine if there is a new instance created on every request or not.
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall,ConcurrencyMode=ConcurrencyMode.Single)]
public class TestServiceWithStaticVars : ITestServiceWithStaticVars
{
static int instanceCount = 0;
public TestServiceWithStaticVars()
{
Interlocked.Decrement(ref instanceCount);
}
public string GetInstanceCount()
{
return string.Format("You have created {0} instance", instanceCount);
}
Let you know if the best instance counter is available to use with ease.
[Edit] as I cannot comment now.
Re-assigning to a static variable will take on the new value as you said. Static variables are loaded into HighFrequencyHeap for frequent access. For more information http://www.codeproject.com/Articles/15269/Static-Keyword-Demystified
source to share