Background
This question is in two parts.
I have a one-way WCF operation hosted in IIS 6. The following is my understanding of how this works:
_1. IIS receives a request.
_2. IIS sends an HTTP 202 response (thanks, I’ll process this later).
_3. IIS calls my one-way WCF operation.
Now control passes to my WCF operation which does the following:
_4. Persist the request info to a transactional, durable store.
_5. Start processing the request in the OLTP database.
_6. If there’s an error, repeat from step 5, or take some remedial action, then cleanup the data persisted in step 4.
Question 1
Is my understanding of when IIS sends the HTTP 202 response correct?
Question 2
If IIS recycles between step 2 and step 4, I could lose the request information before I’ve had a change to persist it but after the client thinks I’ve accepted the message. Are there any guarantees provided by IIS about when it will or won’t recycle when there are requests pending?
PS: Please excuse the dodgy formatting. For some reason markdown was totally screwing up my numbered list items.
I’m not sure your assumption is correct.
Even for one-way interaction, WCF can get very invovled before the 202 is returned; if you use authentication, for example, it all has to happen before the method is called and before 202 is returned, so that if there are any problems they can be reported.
If you use wsHttpBinding, for example, out of the box, you will see 2-3 message exchanges resulting in 200 before the actual method call. this is to exchange security information and establish security context.
Admittedly, if you configured your service to have no security, this will not happen and it will return 202 immediately, but this suggests that it has to know whether it can do that from the WCF stack.
All that aside – I’m not sure what you are trying to achieve – which IIS recycling do you refer to? I’m not at all an expert on IIS, but I doubt it would recycle the host while something is actively executing; if you are refering to anyone manually restrting the application pool (or IIS, or the machine for that matter) I doubt there’s much you can do.
If you have to know for sure that a message is not lost the only way I know to guarentee that is by employing reliable messaging in one way or another, which only acknowledges requests once persisted in a durable store;