How do you detect when the connection breaks when a web service is returning a result?

In a C# ASP .NET application I have a web service that receives a DataSet, processes it, and returns it.

Returning it can take up to a minute over a slow connection. What happens in the background if that connection breaks after the last line of the web service method has run but while the data is still being sent?

I tried wrapping my web service's code in a catch block and disconnecting the connection while it was downloading, but no exception was thrown in the web service. I'd to detect the error somehow like this:

[WebMethod(Description = "Process data")]
public DataSet Process(DataSet data)
{
   bool success = true;
   StartDatabaseTransaction();
   DataSet result = Process(data);
   try
   {
      return result; //quickly pull out cable after running this
   }
   catch
  开发者_JS百科 {
      success = false;  //never gets here
   }
   finally 
   {
      if (success) CommitTransaction(); else RollBackTransaction();
   }
   return null;
}

---

If I read your question and code correctly, you will never hit the catch because of the way webmethods work. If you are looking to trap a timeout error it needs to be in the receiving method of the dataset. At the point of the return, it is the webserver that is working to transform and transmit the data.

---

I'm not sure this is the right approach, but If It is that important, you need to create your own "approve" call from the caller to the server. once the server sends it's reply, I don't think it waits for the acknowledge.

some ways around it: using a messaging system (msmq) between the web server and the web service, I think with messaging you can achieve this goal as a guarantied delivery service

Or - make the client send a guid with the call, and have the web service log it. if the client doesn't get the response on time, let him issue the call again with the same guid. if the server already have this guid logged, it means that the call was process (and you need to deal with it according to your business logic).