Good C#.NET Solution to manage frequent database polling

Question

I am currently working on a c# .NET desktop application that will be communicating to a database over the internet via WCF and WCF Data Services. There will be many spots in th

Answer 1

If the expensive operation is the server to pooling the database, you should implement some sort of caching. It can be basic as ASP.NET caching or advanced as using memcached.

But if the expensive operation is the client pooling the server, you can use an Atom or RSS feed with PubSubHubbub to minimize the number of requests to the server. It'll get cheaper since there are some free PubSubHubbub publishers that will handle the load.

Answer 2

you can define a callback interface in the WCF connection like this:

[ServiceContract(CallbackContract = typeof(IFooClient))]

As the client initiates the connection the should work through the firewall. The the server can method to register for changes an you can get the callback interface with

IFooClient client = OperationContext.Current.GetCallbackChannel<IFooClient>();

and callback all the clients that are registered on data changes.

Answer 3

I think you might want to go with a combination of two approaches. First off, you could use long polling from the client to server so that the server can notify the client as soon as a change occurs that the client is interested in.

A new technology that handles the above suggestion quite nicely in ASP.NET is SignalR. This handles much of the details of long polling (or uses WebSockets when it can) so you don't have to worry about it.

Secondly, based on the tags in this question it looks like you're using SQL Server. You could use database notifications on the tables you are interested in to have the DB notify your service when changes occur. This could then trigger the service to notify the client about the changes through the long poll connections. You can do this using the SqlDependency class.

I'm sure there are other ways, but this would probably scale quite well as you'd only have one service getting the notifications and then distributing them out to all the clients.

Answer 4

I don't know why RSS would be simpler than having your web services cache information from the database.

To compare the 2 options, let's say you need to know who edited an object in a report last (or the last time it was updated, etc.). With an RSS feed, you'll have to make a request for the feed, get it, parse it, and take action based on the relevant values. With a web service call that memoizes and caches it's database call, you just call the service and take action on the result. The only time I could see RSS being better is if 1) You are supporting multiple clients you either don't control or aren't .Net clients and 2) You are taking action based on a lot of the polled values at the same time.

Answer 5

You could look into the Service Broker, that way you won't have to poll for updates