Invoking a function in a Windows Service

[CaptainCaveman]

Hi,

I'm writing a Windows service that will continually poll multiple devices on
my network.
To manage this each device will have it's own thread, and therefore will
asynchronously return status messages to my service to be handled.
These messages will be added to a database and I want to manage them all
from one place.

If this was a normal Windows Form I would use Form.Invoke. The Windows
Service does not have this functionality, so what would I need to use
instead.

If this is not possible then I would guess that the alternative is to detect
the database table status before writing to the database.

TIA

 

[Alberto Poblacion]

I'm writing a Windows service that will continually poll multiple devices
on my network.
To manage this each device will have it's own thread, and therefore will
asynchronously return status messages to my service to be handled.
These messages will be added to a database and I want to manage them all
from one place.

If this was a normal Windows Form I would use Form.Invoke. The Windows
Service does not have this functionality, so what would I need to use
instead.

If this is not possible then I would guess that the alternative is to
detect the database table status before writing to the database.

You shouldn't need to do anything on the database side to allow access
from multiple threads. If multiple threads send an "Insert into MyTable...",
the database server will properly coordinate the requests by means of locks
on the table and indexes, in a way that will be transparent to the calling
program. The only catch is that the only easy way to use the connection to
the database from multiple threads is to have each thread open a separate
connection. This should be easy if you are opening and closing the
connection from a local variable in the method that performs the database
insert. The connection pool will automatically allocate a new connection if
existing connections are still in use at the time that a thread requests a
new connection to be opened.

 

[Paul]

Abstract your data tier into either a Webservice/WCF application. Each
distinct function can then use this middle tier to write data to the DB.

Services should do nothing other than act as a service, doing so runs the
risk of a failure terminating a service and all applications attached to the
service.

So your service becomes a UI

__________________________________
SERVICE
__________________________________


_____________ _____________

Device 1 Poller Device 2 Poller
_____________ ______________

__________________________________
DAL Facade/WS
__________________________________


__________________________________
DAL
__________________________________

 

[Paul]

HMMM I forgot to mention the BLL functions (Calling the Devices for their
state) should also be abstracted behind WCF/WS this way all the threading is
handled for you, and your service just acts as a timer. You could create App
Domains for each distinct bit of functionality but why when the .NET
framework provides you a more than adequate way to do what you want in any
case. This also probably negates the need for the DAL to have a facade but
that depends on exactly what is and is not to call it.