What is the difference between marking a WCF method with
[OperationContract(IsOneWay = true)]
attribute and checking the generate asynchronous operations checkbox when adding a service reference?
From what I have read, it seems the asynchronous nature of the call should only be defined on the client side.
If that's the case, what is the point of the [OperationContract(IsOneWay = true)]?
Right now, I just have the following method running in the WCF method.
public void UpdateIndex(IndexElement[] indexElements)
{
// start the update on a new thread.
Thread thread = new Thread(() => UpdateIndexThread(indexElements));
thread.Start();
}
I created a service reference in my client's code, and I simply call:
indexerClient.UpdateIndex(indexElements);
Where indexerClient is an instance of my WCF service.
Should this also work? It doesn't seem to, it's almost as though it waits for the thread to complete before returning.
These are very different.
At a conceptual level, IsOneWay=true says that the messaging pattern is 'fire and forget' as opposed to e.g. 'request-response'. That is, IOW=true means there is a message from the client to the server, but not a reply from the server to the client. In contrast, a non-IOW=true method will typically have a response message, even if the return type is void (e.g. an 'empty' message).
The async pattern is for how the client code behaves - e.g. does it block waiting for the return value or not. Async is a 'local' thing, see this blog for details. You can have an async client for a sync server or a sync client for an async server. WCF will do the magic under the hood to give you either programming model. If you have e.g. a request-response messaging pattern and use 'generate async', the generated client will give you e.g. a method you can call async (e.g. send the message, and get a callback when the reply arrives).
So use 'async' for 'local programming model', and use IOW for 'messaging on the wire'.
Note that in your example, if you mark the method IOW=true, then I think there is no reason for the Thread.Start() in the server code. You can just do the work right there on the thread WCF has given your server.