I have a WCF service using the per-instance call pattern. It is self-hosted, not using IIS at all.
The service class instances another class with the pattern
var myfoo = new Foo().GetResultFromDictionary(something);
The Foo class reads from an embedded resource, does some lookups, and returns an object of Bar that the service class then uses.
Creating a new instance for a single call on Foo() seems like a waste. Once it loads, all instances of the service should be able to make the call.
Does anyone have design recommendations for this? I do not want to fall into the trap of over-optimizing and pre-optimizing if there is no problem here (eg if .NET Framework will take care of instance management for Foo), but I'm not sure.
All ideas appreciated, thanks.
I am going to work through the System.Runtime.Caching bits, creating a static class that inserts into MemoryCache.Default when the static "constructor" is called, and reading from the cache on all subsequent calls.
Related
Just want to confirm my understanding is correct. If I use Single instance mode for a service:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
and this service calls a class from another asssembly which has a static constructor, that constructor is only called the first time ther service is called? The constructor I am talking about sets up a fair number of AutoMapper maps, and I only want this overhead the first time the service is called.
Taking this further, If I have two different services, and they both us the shared class, am I correct that the static constructor is still only called once?
Best
Ray
There is no connection between InstanceContextMode and how many times static constructor is fired. Static constructor is called once per Application Domain. So if your services are hosted within one Application Domain then your constructor will be called once.
As far as I understand you use the contructor to register AutoMapper configuration... To me it is not a good approach. Assuming your services are hosted on IIS you would better create a Global.asax file and then run you mapping registration code in Application_Start method. Of cource you can wrap it in some static method first.
Hope it helps!
I made a simple PasteBin demo example of what my code looks like: http://pastebin.com/GpDhPRVm
My actual Process object is extremely complex that includes adding collections of Tasks, Documents, Workflows, etc into a Process object and setting properties through methods, etc.
My PasteBin example is as simple as I can make it to show where things break down. Including the Process object in the CreateNewProcess method in my service (shown in code below), allows the service user to automatically "see" the Process object, properties and enumerators in their instance on the client side.
<ServiceContract()>
Public Interface ICreateProcess
<OperationContract()>
Sub CreateNewProcess(ByVal newprocess As Process)
End Interface
However, it does not allow them to use any of the methods like the 'AddTask' method (shown in PasteBin example) and it also doesn't expose the Task or TaskCollection objects. Even if I decorate the methods with DataContract, OperationContract, etc they still are not visible to the client service.
This is my major issue: I need the client service to be able to fully "build" the Process object and then pass it in to the CreateNewProcess method.
Another small note: (to avoid comments asking me about it) is that I made sure that all of my properties are simple types that are interoperable since this needs to be able to work for Java - not just .NET clients.
Ok, I figured it out with a little help from a buddy of mine.
Can't use methods at all outside the .svc service class; only properties, enums and sub objects will translate down to the client. (I figured this)
Then, instead of using a Collection, you have to use a generic List type.
So, instead of this:
Public Tasks As New TaskCollection() 'where TaskCollection inherits from Collection
I needed to do this:
Public Tasks As List(Of Task)
And the client will just have to build their own array of Tasks and assign it to the t.Tasks property.
This works like a charm now: http://pastebin.com/rt8HwsXY
I have a wcf service singleton type, and in the same application an ASP page that uses a service-specific function.
As I can get a reference to the service instance created, not to run twice the manufacturer's service?
My service is published on IIS
I'm guessing you are saying that you have a service that is supposed to be a singleton and because you're in the same AppDomain you can simply create an instance as well.
If you own the service code you can make it a singleton using the Singleton Pattern (there are a number of ways to do that in .NET and Jon Skeet has a list of them here).
Then you need to deal with how does WCF get hold of the instance? In that case there are two options:
Use a ServiceHostFactory and hand the instance to the ServiceHost you create
Implement IInstanceProvider and plumb that in
If you don't control the service class then there is nothing you can do to prevent people creating instances but you can wrap the class in your own singleton and stipulate access must only be via the singleton so it is less likely that someone will create a second instance
Say I have a simple WCF application that the client calls in order to get a number. There's not much processing in it and the service contract is attributed as SessionMode=SessionMode.NotAllowed.
When is the constructor called? When is the object destructed? Is a constructor called per request?
Are there any reference documents or resources that have this information? I can't seem to find it.
WCF is hosted by IIS, and thus subject to its lifetime rules. A service class, by itself, will probably be created and destroyed as necessary within the app; the class will be constructed upon receipt of a request, the method called, and the result returned, after which the object will leave scope and be disposed/finalized.
However, the project containing your service looks like an ordinary ActiveServer.NET web app to IIS (check out the Global.asax file that should be in it; it contains a class of type HttpApplication, and represents the entry point for the app that IIS can use to control it), and IIS will maintain a "pool" of these applications to handle requests from multiple clients. As long as requests keep coming in, and IIS doesn't decide an app has gotten "stale" and refreshes it or the entire pool, the application will continue to run. So, any static classes you declare, for instance your singleton IoC container, or anything you add to a derived HttpApplication class that you use as your child type, will remain in memory until the app is recycled.
I have been trying to get up to speed on Named Pipes this week. The task I am trying to solve with them is that I have an existing windows service that is acting as a device driver that funnels data from an external device into a database. Now I have to modify this service and add an optional user front end (on the same machine, using a form of IPC) that can monitor the data as it passes between the device and the DB as well as send some commands back to the service.
My initial ideas for the IPC were either named pipes or memory mapped files. So far I have been working through the named pipe idea using WCF Tutorial Basic Interprocess Communication . My idea is to set the Windows service up with an additional thread that implements the WCF NamedPipe Service and use that as a conduit to the internals of my driver.
I have the sample code working, however I can not get my head around 2 issues that I am hoping that someone here can help me with:
In the tutorial the ServiceHost is instantiated with a typeof(StringReverser) rather than by referencing a concrete class. Thus there seems to be no mechanism for the Server to interact with the service itself (between the host.Open() and host.Close() lines). Is it possible to create a link between and pass information between the server and the class that actually implements the service? If so, how?
If I run a single instance of the server and then run multiple instance of the clients, it seems that each client gets a separate instance of the service class. I tried adding some state information to the class implementing the service and it was only retained within the instance of the named pipe. This is possibly related to the first question, but is there anyway to force the named pipes to use the same instance of the class that is implementing the service?
Finally, any thoughts on MMF vs Named Pipes?
Edit - About the solution
As per Tomasr's answer the solution lies in using the correct constructor in order to supply a concrete singleton class that implements the service (ServiceHost Constructor (Object, Uri[])). What I did not appreciate at the time was his reference to ensuring the service class was thread safe. Naively just changing the constructor caused a crash in the server, and that ultimately lead me down the path of understanding InstanceContextMode from this blog entry Instancecontextmode And Concurrencymode. Setting the correct context nicely finished off the solution.
For (1) and (2) the answer is simple: You can ask WCF to use a singleton instance of your service to handle all requests. Mostly all you need to do is use the alternate ServiceHost constructor that takes an Object instance instead of a type.
Notice, however, that you'll be responsible for making your service class thread safe.
As for 3, it really depends a lot on what you need to do, your performance needs, how many clients you expect at the same time, the amount of data you'll be moving and for how long it needs to be available, etc.