Here are my basic assumptions:
Wcf executes my service operation methods on IOCP threads (UnsafeQueueNativeOverlapped) instead of normal ThreadPool threads (QueueUserWorkItem).
Blocking I/O should not be done inside of one-way service operation methods.
Blocking I/O should not be done inside of a normal ThreadPool thread.
I believe that the best strategy is to chain async calls. So, if I receive a message into my one-way service operation, I then do an async call to my db and when that completes, do my next async db call, etc. and finally respond via my wcf callback...
However, it's hard to do every single database call async. I have resorted to breaking rules 2 and 3 above, but I don't like it because I believe this will starve the ThreadPool eventually. Are there any better strategies?
I have looked into using Jon Skeet's CustomThreadPool, but I'm not sure if that's the answer either.