none
Sytem.Timers.Timer RRS feed

  • Question

  • Ok.. dumb question about an App using a Timer.

     

    I have a Windows Service that has a System.Timers.Timer that every interval calls a Method which calls various Stored Procs to pick up the next record to process from a DB to create records in another DB.

     

    My question is if the first record being processed does not complete before the Timer picks up the next record, will this cause any issues or is it because everything is local variables (ie SqlConnections and DataReaders), this will be fine and it just runs the proc simultaneously for the next record? Since a Timer is not a Thread... I am a little confused though think I want to use a Timer not a mulit-threading.

     

    Thanks heaps!

    Sunday, February 24, 2008 5:37 AM

Answers

  • It may depend on what your sprocs are doing.  An easy way to ensure that there are no conflicts or that there is no distributed transaction is to just stop the timer while you are running all of your sprocs, then restart the timer when you are done.  so if you have a timer that runs every 60 seconds and it takes 30 seconds to process all of your sprocs, it will be 90 seconds between runs.  This actually may be more desirable than just letting the timer run.

    Sunday, February 24, 2008 9:25 PM

All replies

  • It may depend on what your sprocs are doing.  An easy way to ensure that there are no conflicts or that there is no distributed transaction is to just stop the timer while you are running all of your sprocs, then restart the timer when you are done.  so if you have a timer that runs every 60 seconds and it takes 30 seconds to process all of your sprocs, it will be 90 seconds between runs.  This actually may be more desirable than just letting the timer run.

    Sunday, February 24, 2008 9:25 PM
  • Thanks very much for the answer Dan. I didn't think about stopping the timer.

     

    I ended up setting a var to check and only start another one if the first had not finished. It was mainly so that my Log files were easier to read than any processing conflicts really.

     

    Ta.

     

     

     

    Saturday, March 8, 2008 2:10 AM