Windows Service

[Chris Marsh]

All

I have a database table, changes to the data within which I am interested in
acting on. The approach that I'm taking is to have the database update a
file every time data is updated. This process is outside my domain - I can
rely on the file being updated when data changes.

Within my domain is the design of a Windows service to perform the
operations required when the data changes. I have not produced a Windows
service before (being mostly a web application .NET developer), but the
process seems fairly straightforward. My Windows service will poll the file
(using a Timer object), and when the file has been updated the Windows
service will access the database, fetch the data that has changed, and
perform the required operations on it. This involves contacting web services
provided by a different system.

My questions are as follows:

1. Are there any issues with this approach that anyone would care to draw to
my attention?

2. Since it is conceivable that more than one record has changed in the
database, should I perform my operations on each record concurrently using
different threads?

3. Given my lack of experience with Windows services, are there any specific
areas that anyone would recommend I study up on before proceeding?

I realise that these questions are fairly open ended, but I'm wary about
introducing problems into our system due to my lack of experience. I want to
ensure that I don't produce a subsystem that *appears* to work, but
introduces subtle problems at a later date that are perhaps difficult to
pick up immediately.

Any comments are appreciated; many thanks in advance one and all!

 

[Kevin Spencer]

1. Are there any issues with this approach that anyone would care to draw

to my attention?

Rather than using a timer, use a FileSystemWatcher class, which can watch
the file and raise an event when it changes. A FileSystemWatcher simply
subscribes to file system events.

Also, make sure to implement safeguards that will prevent the service from
stopping when an exception occurs. A Windows Service runs unattended, so it
must be very robust. You may want to implement some kind of alert system for
the service when an exception occurs as well. We have, for example, a
service that sends an email to me when an exception occurs.

2. Since it is conceivable that more than one record has changed in the
database, should I perform my operations on each record concurrently using
different threads?

I don't follow you. You said that the database is outside your domain, and
didn't mention more than one file. In addition, you said that the database
would update "a file," which doesn't make sense. A database can update a
table, but not a file.

3. Given my lack of experience with Windows services, are there any
specific areas that anyone would recommend I study up on before
proceeding?

Debugging Windows Services is difficult. Our approach is to put the
functionality for the service into a class library, which we can test using
a Windows Forms user interface. Then you can host the class(es) in your
Service once you're sure they are working correctly.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Chris Marsh]

Kevin

Many thanks for the response.


[snip good advice which I will follow]

I don't follow you. You said that the database is outside your domain, and
didn't mention more than one file. In addition, you said that the database
would update "a file," which doesn't make sense. A database can update a
table, but not a file.

Apologies for not expressing myself well.

The database is indeed out of my (development) domain, in the sense that I
will not be doing any database development personally. My Windows service
needs to know when records have been added to a database table, so that it
can fetch the records, perform an operation on each, and then delete each
record when confirmation of operational success has been received.

My assumption was that polling the database table for changes every couple
of seconds would be an expensive operation, so instead the Windows service
could monitor a file (a specific file created for this purpose). When the
last modified date/time of the file changes, the Windows service would know
that there was data in the database table to operate on. This would be the
case, because an insert trigger on the database table would update the file,
thus changing the last modified date/time. I would not be implementing this
trigger, but I've been told that it's possible to do thing this way.

Debugging Windows Services is difficult. Our approach is to put the
functionality for the service into a class library, which we can test
using a Windows Forms user interface. Then you can host the class(es) in
your Service once you're sure they are working correctly.

I was going to take this approach - it's good to see that this is a good
idea.

HTH,

A lot, thank you Kevin.

 

[Kevin Spencer]

You're very welcome, Chris. Thanks for clearing up the question about the
file. I would NOT use multiple threads, since you're watching a single file,
and you can only read it once at a time. You might want to use a separate
thread for the FileSystemWatcher, as changes might happen to the file while
you are handling the last group of changes. The FileSystemWatcher could use
a Message Queue to communicate to the Main Thread when a change occurs, so
that if the Main thread is busy making changes when an event fires, it will
pick it up from the Queue as soon as it's ready.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Kevin

Many thanks for the response.


[snip good advice which I will follow]

I don't follow you. You said that the database is outside your domain,
and didn't mention more than one file. In addition, you said that the
database would update "a file," which doesn't make sense. A database can
update a table, but not a file.

Apologies for not expressing myself well.

The database is indeed out of my (development) domain, in the sense that I
will not be doing any database development personally. My Windows service
needs to know when records have been added to a database table, so that it
can fetch the records, perform an operation on each, and then delete each
record when confirmation of operational success has been received.

My assumption was that polling the database table for changes every couple
of seconds would be an expensive operation, so instead the Windows service
could monitor a file (a specific file created for this purpose). When the
last modified date/time of the file changes, the Windows service would
know that there was data in the database table to operate on. This would
be the case, because an insert trigger on the database table would update
the file, thus changing the last modified date/time. I would not be
implementing this trigger, but I've been told that it's possible to do
thing this way.

Debugging Windows Services is difficult. Our approach is to put the
functionality for the service into a class library, which we can test
using a Windows Forms user interface. Then you can host the class(es) in
your Service once you're sure they are working correctly.

I was going to take this approach - it's good to see that this is a good
idea.

HTH,

A lot, thank you Kevin.

 

[William Stacey [C# MVP]]

hmm. Instead of doing this at file level, does the DB product support
Notifications of table updates (i.e. SQL Server). If so, that is probably
the high-road solution.
If they have (or will have) SOA/WCF apis, you can also do same type of thing
with WCF callbacks. You may not be in control of the DB, but they need to
provide some type of event functionality if they want your part of the
solution robust. Actually, another option would be Sql Service Broker that
may have other benefits for this type of app. I would feel kinda dirty
taking a dependancy on FileSystem watcher for this type of thing. Could be
wrong.

--
William Stacey [C# MVP]



| Kevin
|
| Many thanks for the response.
|
| |
| [snip good advice which I will follow]
|
| >> 2. Since it is conceivable that more than one record has changed in the
| >> database, should I perform my operations on each record concurrently
| >> using different threads?
| >
| > I don't follow you. You said that the database is outside your domain,
and
| > didn't mention more than one file. In addition, you said that the
database
| > would update "a file," which doesn't make sense. A database can update a
| > table, but not a file.
|
| Apologies for not expressing myself well.
|
| The database is indeed out of my (development) domain, in the sense that I
| will not be doing any database development personally. My Windows service
| needs to know when records have been added to a database table, so that it
| can fetch the records, perform an operation on each, and then delete each
| record when confirmation of operational success has been received.
|
| My assumption was that polling the database table for changes every couple
| of seconds would be an expensive operation, so instead the Windows service
| could monitor a file (a specific file created for this purpose). When the
| last modified date/time of the file changes, the Windows service would
know
| that there was data in the database table to operate on. This would be the
| case, because an insert trigger on the database table would update the
file,
| thus changing the last modified date/time. I would not be implementing
this
| trigger, but I've been told that it's possible to do thing this way.
|
| >> 3. Given my lack of experience with Windows services, are there any
| >> specific areas that anyone would recommend I study up on before
| >> proceeding?
| >
| > Debugging Windows Services is difficult. Our approach is to put the
| > functionality for the service into a class library, which we can test
| > using a Windows Forms user interface. Then you can host the class(es) in
| > your Service once you're sure they are working correctly.
|
| I was going to take this approach - it's good to see that this is a good
| idea.
|
| > HTH,
|
| A lot, thank you Kevin.
|
| --
| Regards
|
| Chris Marsh
|
|

 

[Kevin Spencer]

I agree, William. I'm not sure that the OP's time constraints would give him
the opportunity to study up on this. It would be a better solution, however.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

hmm. Instead of doing this at file level, does the DB product support
Notifications of table updates (i.e. SQL Server). If so, that is probably
the high-road solution.
If they have (or will have) SOA/WCF apis, you can also do same type of
thing
with WCF callbacks. You may not be in control of the DB, but they need to
provide some type of event functionality if they want your part of the
solution robust. Actually, another option would be Sql Service Broker
that
may have other benefits for this type of app. I would feel kinda dirty
taking a dependancy on FileSystem watcher for this type of thing. Could
be
wrong.

--
William Stacey [C# MVP]



| Kevin
|
| Many thanks for the response.
|
| |
| [snip good advice which I will follow]
|
| >> 2. Since it is conceivable that more than one record has changed in
the
| >> database, should I perform my operations on each record concurrently
| >> using different threads?
| >
| > I don't follow you. You said that the database is outside your domain,
and
| > didn't mention more than one file. In addition, you said that the
database
| > would update "a file," which doesn't make sense. A database can update
a
| > table, but not a file.
|
| Apologies for not expressing myself well.
|
| The database is indeed out of my (development) domain, in the sense that
I
| will not be doing any database development personally. My Windows
service
| needs to know when records have been added to a database table, so that
it
| can fetch the records, perform an operation on each, and then delete
each
| record when confirmation of operational success has been received.
|
| My assumption was that polling the database table for changes every
couple
| of seconds would be an expensive operation, so instead the Windows
service
| could monitor a file (a specific file created for this purpose). When
the
| last modified date/time of the file changes, the Windows service would
know
| that there was data in the database table to operate on. This would be
the
| case, because an insert trigger on the database table would update the
file,
| thus changing the last modified date/time. I would not be implementing
this
| trigger, but I've been told that it's possible to do thing this way.
|
| >> 3. Given my lack of experience with Windows services, are there any
| >> specific areas that anyone would recommend I study up on before
| >> proceeding?
| >
| > Debugging Windows Services is difficult. Our approach is to put the
| > functionality for the service into a class library, which we can test
| > using a Windows Forms user interface. Then you can host the class(es)
in
| > your Service once you're sure they are working correctly.
|
| I was going to take this approach - it's good to see that this is a good
| idea.
|
| > HTH,
|
| A lot, thank you Kevin.
|
| --
| Regards
|
| Chris Marsh
|
|

 

[Chris Marsh]

Kevin/William

I agree, William. I'm not sure that the OP's time constraints would give
him the opportunity to study up on this. It would be a better solution,
however.

Many thanks for the valuable information. I'm going to see how much time I
can get to work on this, and then implement the most robust solution that I
can.

Many thanks for both of your assistance.