January 27, 2005 at 10:27 am
Hi,
I am writing a piece of code which will be multi-threading, and may even be running on several machines at once.
The code needs to read data out of a database, perform some actions on it and then write the result back to the database. To reduce server round-trips, I am thinking of getting a 'chunk' of data at a time from the database, processing it all, then writing all of the results back in one go (which may be some time later).
The problem is - how to stop one thread doing work already being undertaken by another. One thought was to include a column in the database to store the ID of the thread currently working on that data. The problem with this is what happens if the thread dies for some reason - the data will never get processed. Unless I store the time the thread started work on it - then I could add a timeout feature.
All sounds a bit rough around the edges to me. Anyone got any better ideas?
Any help would be greatly appreciated!
Thanks,
- Chris
January 27, 2005 at 10:55 am
Instead of having each thread do the all the work of getting the data and such you might want to consider using a diconnected recordset (still might want a stage flag for you data) and use common storage to all of your threads,
then as each thread is working thru it you can signal a record in use with the stage flag and complete when done. This way you know what is being processed by other threads and when they have been processed.
This is just a thought off the top of my head.
January 28, 2005 at 1:08 pm
You may want to shoot me, but what you've described could almost be implemented using a merge replication scenario. See BOL if interested...
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply