I'd like to implement QueueUserWorkItem for some parts of the app;
specifically for DB related caching and file i/o. Example: When the
user finishes work on a file, I'd like to process the file persistence
(some data to db + file system as zip) in the background. I haven't
worked with ThreadPool before so am asking for ideas/guidance for
implementation.
On the client side (WinForm), I'm likely to be remoting for some db
cache load/lookup. I have a DB "Service" singleton class which
centralizes DB layer access for the client and a singleton "Cache"
class for storing various other details. The FileSystem related class
is not a singleton, but can be converted to it. Some of the methods in
all 3 classes are candidates, in my opinion, for ThreadPool (like
save/read/zip/unzip a file, load all cache from DB/IIS). The app will
be running in Terminal Services against a network file share.
Do you think using the ThreadPool in this scenario a good idea? I'm
currently looking at ThreadPoolThrottle
(http://msdn.microsoft.com/msdnmag/is...12/NETMatters/) and
thinking what would be a clean way to implement QueueUserWorkItem such
that I can identify which methods in the singleton should block for a
job to finish while other methods can let the request pass through?
Thanks for any ideas.