Question

I have a WCF service that will serve multiple clients.
They will have operation like ‘Accept Suggested Match’ or ‘Reject Suggested Match’.
I would like all the operations to be run serially, but I am afraid this will have an impact on performance.

From what I saw – the default (and most used) instancing is ‘Per Call’ and the default concurrency mode is single.

So is it true I would need to use ‘Single’ mode in the concurrency ?
And how bad of an impact is it ?

(I estimate tens of clients using the system at the most).

Is there any way to enjoy both worlds ?

Use parallel computing (the service communicates with a database) and still perform the operations serially ?

In this post I read about ‘Instance mode = Per Call and Concurrency = Single’:

• For every client instance, a single thread will be allocated.
• For every method call, a new service instance will be created.
• A single thread will be used to serve all WCF instances generated from a single client instance.

It seems like this doesn’t guarantee to me that operation calls will be performed serially !

For example, if this happens :

1. CLIENT ALPHA calls ‘Operation A’
2. CLIENT ALPHA calls ‘Operation B’
3. CLIENT BETA calls ‘Operation C’

From what I read – it says ‘A single thread will be used to serve all WCF instances generated from a single client instance‘. This sounds to me like it means that CALL 1 and CALL 2 would be performed serially, but CALL 3 might be performed between them, because it is from a different client thread.

Is this true ? Is there no way to make sure that calls are handled at the order they arrive ?

And can someone tell me if it is a bad practice or are there real world scenarios where it is accepted and recommended to use this method of communication in WCF.

Thank you very much

Answer 1

I think there are 3 ways to answer this question

1. A direct answer
2. An alternative approach for situations where you control the clients and the server
3. An alternative approach where you don’t control the clients

I’d like to give answers 2 and 3 first (because I think they are better) but I will give a direct answer at the end…I promise!

I believe your problem is not that you need to process messages in the order they are received by the service, it is that since you have independent clients, you cannot guarantee that they are received by the service in the same order they are sent from the clients.

Consider your example of clients ALPHA and BETA. Even though client ALPHA might send the request to call operation 2 before client BETA calls operation C, you have no way of knowing what order they will be received by the service. This means that even if you process them at the server in the order they are received, this might still be the “wrong” order.

If you agree with this, carry on reading. If not, go straight to the direct answer at the bottom of this post ;o)

Approach 1: Use WS-Transactions

If you control both the service and the clients, and if the clients are capable of implementing WS-* SOAP protocols (e.g. .Net WCF clients). Then you could use the WS-Transaction protocol to make sure that operations from a single client that are intended to be processed in a single long-running transaction are definitely done that way.

For details of how to do WS-Transcation with WCF, look at

http://msdn.microsoft.com/en-us/library/ms752261.aspx

Following you example with clients ALPHA and BETA, this would enable client ALPHA to

• Start a transaction
• Call operation 1
• Call operation 2
• Commit the transaction

The effect of the ALPHA starting a transaction on the client is to flow that transaction through to the server so it can create a DB transaction which guarantees that operation 1 and operation 2 complete together or not at all.

If client BETA calls operation 3 while this is going on, it will be forced to wait until the transaction commits or aborts. Note that this might cause operation 3 to time out in which case BETA would need to handle that error.

This behaviour will work with any InstanceContextMode or ConcurrencyMode.

However, the drawback is that these kind of long running, distributed transactions are not generally good for scalability. Today you have 10s of client, but will that grow in the future? And will the clients always be able to implement WS-Transaction? If so, then this could be a good approach.

Approach 2: Use an “optimistic” type approach

If you need to support many different client types (e.g. phones, browsers etc.) then you could just allow the operations to happen in any order and make sure that the service and client logic can handle failures.

This might sound bad, but

• you can use database transactions on the server side (not the WS-Transaction ones I mentioned above) to make sure your database is always consistent
• each client can synchronise its own calls so that in your example, ALPHA would wait for call 1 to complete OK before doing call 2

The drawback here is that you need to think carefully about what failure logic you need and make sure the client and service code is robust and behaves appropriately.

In your example, I mentioned that ALPHA can synchronise its own calls, but if BETA calls operation 3 after ALPHA calls operation 1 but before it calls operation 2, it could be that

1. Operation 2 will fail (e.g. operation 3 has deleted a record that operation 2 is trying to update) in which case you need to handle that failure.
2. Operation 3 will overwrite operation 3 (e.g. operation 3 updates a record and the operation 2 tries to update the same record). In this case you need to decide what to do. Either you can let operation 2 succeed in which case the updates from BETA are lost. Or you could have operation 2 detect that the record has changed since it was read by ALPHA and then fail, or maybe inform the user and have them decide if they want to overwrite the changes.

For a discussion on this in the context of MS Entity Framework see

http://msdn.microsoft.com/en-us/library/bb738618.aspx

for a general discussion of it, see

http://en.wikipedia.org/wiki/Optimistic_concurrency_control

Again, in WCF terms, this will work with any ConcurrencyMode and InstanceContextMode

This kind of approach is the most common one used where scalability is important. The drawback of it is that the user experience can be poor (e.g. they might have their changes overwritten without being aware of it).

Direct answer to the original question

If you definately need to make sure messages are processed in series, I think you are looking for InstanceContextMode.Single

http://msdn.microsoft.com/en-us/library/system.servicemodel.instancecontextmode.aspx

This means that a single instance of the service class is created for the lifetime of the service application. If you also use ConcurrencyMode = Single or ConcurrencyMode = Reentrant this then means that your service will only process one message at a time (because you have a single instance and it is single threaded) and the messages will be processed in the order they are received.

If you use ConcurrencyMode = multiple then your single service instance will process multiple messages at the same time on different threads so the order of processing is not guaranteed.

How bad a performance impact this will have will depend on how long each service call takes to execute. If you get 10 per second and each takes 0.1 second it will be fine. If you get 20 per second and each normally takes 0.1 seconds, you will see a 100% increase in the average time.