Aside from removing the TransactionScope created on the WCF client (and effectively taking msdtc out of the picture), Is there an alternate way to avoid the excessively long WCF-service-wide hang when a single workstation hosting the WCF client is misconfigured (or experiencing communications issues)?
We have a simple WCF service implemented using C#, and a simple WCF Client which creates TransactionScope before invoking the WCF service proxy.
Both work fine as far as concurrency goes if Windows Firewall allows TCP communication from/to msdtc.exe thru firewall. However if a single workstation is misconfigured (i.e. has firewall enabled, and has an Inbound Rule for TCP for msdtc.exe disabled), its attempt to communicate with the service will block all other WCF clients (which are properly configured) from communicating with the WCF Service for at least 41 seconds (given the currect settings for TCP retransmissions), despite us using much shorter timeout settings for the WCF binding as well as for the TransactionScope timeout.
The WCF service is decorated with
InstanceContextMode = System.ServiceModel.InstanceContextMode.PerCall,
ReleaseServiceInstanceOnTransactionComplete = false,
ConcurrencyMode = System.ServiceModel.ConcurrencyMode.Multiple,
IncludeExceptionDetailInFaults = false,
TransactionTimeout = "00:00:13"
The WCF service has a single operation contract, decorated with [System.ServiceModel.TransactionFlow(System.ServiceModel.TransactionFlowOption.Mandatory)] in the class interface.In the class itself, the same method is decorated with [System.ServiceModel.OperationBehavior(TransactionScopeRequired = true)].
The WCF service is hosted using a Windows console application which uses a netTcpBinding configured with transactionFlow="true" transactionProtocol="OleTransactions" sendTimeout="00:00:20" receiveTimeout="00:00:20"
The service is accessed from a Windows Forms client application configured with the following values for its netTcpBinding: