An issue in the SqlClient library could cause transactional writes to happen outside the scope of a distributed transaction. The following circumstances need to be given:
- A transaction scope is present
- A SQL Server connection is opened under the transaction scope
- A transactional WCF endpoint is called within the same transaction scope
- The code interacting with the above resources is executed under high concurrency scenarios
- The transactional WCF client operation throws an exception
If all of these factors are given, the connection that is returned to the connection pool is in a failure state that can make transactional writes to occur even though the distributed transaction hasn’t committed or has rolled back. All writes done via the faulty connection are effectively auto-committed immediately.
The problem is not deterministic and seems to be heavily affected by the level of concurrency as it is only visible in very high concurrency scenarios. It takes 1000s of executions of the above code for the issue to be visible.
Based on our analysis, it appears that the root cause of the problem lies somewhere in the connection pool management. A confirmed workaround for endpoints that are effected is to disable connection pooling.
If you are affected by the problem, we recommend you to apply that workaround and follow the issue in SqlClient repository to monitor the progress of work.
The team in Particular