I am wondering what would be the life time of a static variable in windows service. I have a windows service and static variable to save the messages flowing inside the service. will I get the messages saved on the static variable after the service is restarted?
No, static variables will revert to their original values upon application restart, and a service restart is an application restart.
That answered - if you need a transient data store for messages, you might consider using Entity Framework 4.1 code first with a simple object structure to hold your messages. The framework will create the data store for you safely and it will persist between executions.
Related
I have a WCF service which need to initialize some expensive resources used for all incoming calls. Firstly I used a static variable to record its status, but the variable was reset on every call. Then I used a static service constuctor to init, but it got called on every incoming call. I tried to set InstanceContextMode to Single and PerSession, but neither of them worked.
Any ideas?
Setting your InstanceContextMode to Single is definitely the way to go if you need access to these resources across ALL calls to the service. What probably happened (just a guess) is your worker process is getting recycled, resulting in your initialization code have to run again when a new worker process is started. If that is what is happening, then take a look at this document to configure your application pool to use auto-start.
http://msdn.microsoft.com/en-us/library/ee677260.aspx
If this doesn't help then some additional details on how/where your initialization code is implemented would be helpful.
I currently have 2 static dictionaries in a wcf restful service. These both hold look up data that's not worth putting in a database. Will these stay in memory until the application restarts or should I put them in HttpContext.Current.Application?
The static data will remain until the process recycles or stops, the same as HttpContext.Current.Application.
If you are looking for a more sophisticated caching option, check out the System.Runtime.Caching namespace introduced in 4.0. It is easy to use, works in any .NET application, and offers features like setting expiration times and creating callback functions to execute on expire.
i have an Autocomplete ajax control that calls a WCF service method automatically.
this method gets a string as an input parameter and return a list of strings.
i don't make that call from the client , the control does it, but i write the content of this method.
Can i store some data somewhere in the WCF service when that method is called and extract it later when i use the WCF from the client ?
i mean , i want the control to call the method, in the method i'll store some data and later when i use the WCF client object i'll extract it.
is there such "WCF cache" mechanism?
No, there's no such thing as a 'WCF cache' mechanism. But WCF is .NET, and in a .NET application you can use the Caching Application Block.
Caching has very little if anything to do with WCF. You cache inside your application, but the caching mechanism for a WCF service is fundamentally the same as a Windows Forms application or a managed Windows Service (or an ASMX webservice, or a ASP.NET application, or any .NET application). The only difference is how you use and rely on the cache & how the applicaton's lifecycle is managed.
If your WCF service is hosted in IIS (as is very popular), then when the application pool is recycled (or the website is restarted) you will lose everything in the cache. Will this be a problem?
The typical use case for a cache is when you have a set of data stored (in, say, a database) that will need to retrieved over and over again. Rather than get from the database everytime, you get from the cache. If it's not in the cache, you get from the database and put it in the cache so it's there for next time. It sounds like you want to store some data from the client application in the cache. You can do this, but what will happen if it's not there when you go to retrieve it.
I have a WCF service application (actually, it uses WCF Web API preview 5) that intercepts each request and extracts several header values passed from the client. The idea is that the 'interceptor' will extract these values and setup a ClientContext object that is then globally available within the application for the duration of the request. The server is stateless, so the context is per-call.
My problem is that the application uses IoC (Unity) for dependency injection so there is no use of singleton's, etc. Any class that needs to use the context receives it via DI.
So, how do I 'dynamically' create a new context object for each request and make sure that it is used by the container for the duration of that request? I also need to be sure that it is completely thread-safe in that each request is truly using the correct instance.
UPDATE
So I realize as I look into the suggestions below that part of my problem is encapsulation. The idea is that the interface used for the context (IClientContext) contains only read-only properties so that the rest of the application code doesn't have the ability to make changes. (And in a team development environment, if the code allows it, someone will inevitably do it.)
As a result, in my message handler that intercepts the request, I can get an instance of the type implementing the interface from the container but I can't make use of it. I still want to only expose a read-only interface to all other code but need a way to set the property values. Any ideas?
I'm considering implementing two interfaces, one that provides read-only access and one that allows me to initialize the instance. Or casting the resolved object to a type that allows me to set the values. Unfortunately, this isn't fool-proof either but unless someone has a better idea, it might be the best I can do.
Read Andrew Oakley's Blog on WCF specific lifetime managers. He creates a UnityOperationContextLifetimeManager:
we came up with the idea to build a Unity lifetime manager tied to
WCF's OperationContext. That way, our container objects would live
only for the lifetime of the request...
Configure your context class with that lifetime manager and then just resolve it. It should give you an "operation singleton".
Sounds like you need a Unity LifetimeManager. See this SO question or this MSDN article.
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.