We have a service operation, for which it is very important to ensure that a client receives the status, that was determined at the end of operation.
If client does receive the response, the server status should be "completed". Otherwise (in case of communication error), server status should be rollback and stay as "pending". The possible technical solutions were discussed and WCF Transactions support with 2PC(two phase commit) was selected. We implemented service operation with transaction commit/rollback support and asked our clients to use it.
Our main client is running on Azure. It was a big disappointment, when Readify consultant Himanshu Desai
adviced that WCF Transactions are not supported by Azure.
I did a quick check on Internet and didn't find that is well known issue.
Below are a few quotes to describe the limitation:
2PC in the cloud is hard for all sorts of reasons. 2PC as implemented by DTC effectively depends on the coordinator and its log and connectivity to the coordinator to be very highly available. It also depends on all parties cooperating on a positive outcome in an expedient fashion. To that end, you need to run DTC in a failover cluster, because it’s the Achilles heel of the whole system and any transaction depends on DTC clearing it.
The bottom line is that Service Bus, specifically with its de-duplication features for sending and with its reliable delivery support using Peek-Lock (which we didn’t discuss in the thread, but see here and also here) is a great tool to compensate for the lack of coordinator support in the cloud
In the current release, only one top level messaging entity, such as a queue or topic can participate in a transaction, and the transaction cannot include any other transaction resource managers, making transactions spanning a messaging entity and a database not possible.
Has Windows Azure any kind of distributed transaction mechanism in order to include any remote object creation in an atomic transaction including other domain-specific operations?
The alternative solution suggested by Himanshu Desai is to have an operation to start a process on the server and then poll in a loop on a client until final status is received from the server.