asp.net mvc 4 running a method non stop without it slowing down or blocking application

Question

after looking for several days for a clear answer on this I decided to just ask it here myself.

In my company I'm am tasked to make a web application that is made for Gas and Fire Detection. It talks with a modbus library over modbus tcp/ip. This connection is working verry good and it reads about 1 time each second (although I can easly adjust this).

I've red a lot about AsynControllers and async-await task in the asp.net mvc model. The problem is I have to get this working non stop. So when my application starts for the first time(with the intention of never schutting it down since it will be a control-room kind of app), my application need to start reading and continue on reading while putting this information in a database so I can work with this database for the rest of the application. Since it fire detection this update needs to work all the time and almost instantly.

I was thinking of calling it in the global.aspx so it runs at startup. But of course when I call this method is just blocks my complete application. How can I make this work ?

Any help would be greatly appreciated.

EDIT:

it seems to work with adding: Task.Factory.StartNew(() => { ModbusDB.Main(); });

to the global.aspx!

Answer 1

A web application isn't meant for this sort of "always-on" model. What you're essentially talking about is two applications (which can run on the same web server):

1. A Windows Service (or scheduled console application, whichever you want) which does the background work of interfacing with the external system and updating the application's database. This is the "always-on" part. It polls the external system, gets the data it needs from it, updates the application database. Conversely, it can poll the application database, get the data is needs from that, update the external system. Basically, it does the ongoing background stuff.
2. A Web Application which handles interaction with the users. This isn't "always-on" in the strictest sense. A web application is designed to receive a request and return a response. After that interaction, it's essentially done. Just waiting for other requests. So this application would just interact with the application database and present the users with the interface they need. From the users' perspective, this application is connecting them to that external system. But from a technical perspective it's just a simple web application connecting to a simple database, something else handles the interaction with the external system.

This provides the added benefit of separating your concerns into distinct modules. If you ever need to build another application to interact with that external system (maybe some kind of system-tray-installed monitoring service on people's workstations) then all that application needs to do is interact with the database, not with the external system.

Conversely, if the external system ever changes then you only have to change that background service, not the application(s) that the users use to interact with it.