views:

154

answers:

1

Here are my basic assumptions:

  1. Wcf executes my service operation methods on IOCP threads (UnsafeQueueNativeOverlapped) instead of normal ThreadPool threads (QueueUserWorkItem).

  2. Blocking I/O should not be done inside of one-way service operation methods.

  3. 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.

+1  A: 

I would suggest breaking rule 3 by queuing up synchronous I/O calls for the ThreadPool to perform. The service methods still return immediately, but the work gets done in the background eventually, perhaps kicking off a return notification.

Steven Sudit
Thanks for your response. That is not a bad compromise to make, I will consider that.
wizlb