QueueUserWorkItem: Design guidance

[test.file]

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.

[Roland]

Hi

I personally would suggest to start for each operation a new thread and
to get your methods which are working on the DB and the file system
Thread-Safe.
I don't see any need for a thread pool.

But perhaps I didn't understand your need correctly - just a suggestion.