Wrong isolation level with Sql Azure and TransactionScope

Describe the bug

On SQL Server, executing two queries inside a common TransactionScope, both are executed using the isolation level defined in the TransactionScope, as expected.

The same does not happen on SQL Azure: the second query is executed with the default Azure isolation level that is “Read Committed Snapshot”.

To reproduce

Here the code to reproduce the issue.

  class Program
  {
    const string AzureConnectionString = "Server=tcp:xxxx.database.windows.net,1433;Initial Catalog=xxxx; Persist Security Info=False;User ID=xxx; Password=xxx;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout = 30;";
    const string SqlServerConnectionString = "Server=localhost,1433;Initial Catalog=LCMS;Integrated Security=True";

    static void Main(string[] args)
    {
      Console.WriteLine("SQL SERVER");
      string connectionString = SqlServerConnectionString;
      using (var scope = new TransactionScope(TransactionScopeOption.RequiresNew, new TransactionOptions() { IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted }))
      {
        TestExec(connectionString); // Expected print: "read uncommitted"
        TestExec(connectionString); // Expected print: "read uncommitted"
      }

      Console.WriteLine("SQL AZURE");
      connectionString = AzureConnectionString;
      using (var scope = new TransactionScope(TransactionScopeOption.RequiresNew, new TransactionOptions() { IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted }))
      {
        TestExec(connectionString); // Expected print: "read uncommitted"
        TestExec(connectionString); // Expected print: "read uncommitted", Actual: "read committed snapshot"
      }
    }

    static void TestExec(string connectionString)
    {
      using (var conn = new SqlConnection(connectionString))
      {
        conn.Open();
        var cmd = new SqlCommand()
        {
          CommandText = "dbcc useroptions",
          Connection = conn
        };

        var reader = cmd.ExecuteReader();
        while (reader.Read())
        {
          if (reader.GetString(0) == "isolation level")
            Console.WriteLine(reader.GetString(1));
        }
      }
    }
  }

Expected behavior

A a new SqlConnection opened inside a TransactionScope must have the same isolation level defined in the TransactionScope.

Further technical details

Additional context The issue seems related to the connection pooling and the sp_reset_connection, because does not happen using Pooling=No in the connection string.

[asos-martinsmith]

What is the progress on the fix for this and why is it marked as “low priority”?

We have an application using Snapshot isolation.

It does a read and if a condition is met then does a write.

We are dependent on the documented behaviour

If a snapshot transaction attempts to commit modifications to data that has changed since the transaction began, the transaction will roll back and an error will be raised.

to give us an optimistic concurrency exception - this is broken for us because the isolation level gets reset before the write that would raise this exception so we don’t get the expected exception,

EDIT:

Though a workaround is to add an explicit

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

in the relevant SQL

[tbolon]

I am surprised this problem is still relevant.

See this code, which simply use a new TransactionScope() without any option:

using Microsoft.Data.SqlClient;
using System.Transactions;

class Program
{
  const string AzureConnectionString = "Server=tcp:xxx.database.windows.net,1433;Initial Catalog=xxx; Persist Security Info=False;User ID=xxx; Password=xxx;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout = 30;";
  const string SqlServerConnectionString = "Server=.\\SQLEXPRESS;Initial Catalog=xxx;Integrated Security=True;Encrypt=false";

  static void Main(string[] args)
  {
    Console.WriteLine("SQL SERVER");
    string connectionString = SqlServerConnectionString;
    using (var scope = new TransactionScope())
    {
      TestExec(connectionString); // Expected print: "serializable"
      TestExec(connectionString); // Expected print: "serializable"
    }

    Console.WriteLine("SQL AZURE");
    connectionString = AzureConnectionString;
    using (var scope = new TransactionScope())
    {
      TestExec(connectionString); // Expected print: "serializable"
      TestExec(connectionString); // Expected print: "serializable", Actual: "read committed snapshot"
    }
  }

  static void TestExec(string connectionString)
  {
    using (var conn = new SqlConnection(connectionString))
    {
      conn.Open();
      var cmd = new SqlCommand()
      {
        CommandText = "dbcc useroptions",
        Connection = conn
      };

      var reader = cmd.ExecuteReader();
      while (reader.Read())
      {
        if (reader.GetString(0) == "isolation level")
          Console.WriteLine(reader.GetString(1));
      }
    }
  }
}

And the output:

SQL SERVER
serializable
serializable
SQL AZURE
serializable
read committed snapshot

That means thay basically, the transaction scope transaction level is ignored when running more that one connection per TransactionScope (which is the recommended way to code : do not share a connection, instead open and close it when not needed, and expect the pooling will manage them.

I am surprise that all documentation still state that TransactionScope sets a Serializable scope by default and it’s never documented that the isolation level is not supported on Azure Sql Db (or buggy because it’s only ok for the first SqlConnection opened).

It does not seems that this bug is specific to Microsoft.Data.SqlClient (System.Data.SqlClient has the same behavior), and it should be redirected to the dotnet/runtime repo if TransactionScope or the documentation must be amended.

See also this:

• What does “exec sp_reset_connection” mean in Sql Server Profiler? [duplicate]
• What does sp_reset_connection do?
• SQL Server: Isolation level leaks across pooled connections
• https://web.archive.org/web/20160117124649/http://blogs.msdn.com/b/jimmymay/archive/2009/02/02/sp-reset-connection-does-not-reset-transaction-isolation-level-unexpected-behavior-by-design.aspx