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/issues/04/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.