开发者

IsolationLevel problem. Can't access table even if set to ReadUncommited

开发者 https://www.devze.com 2023-02-18 19:36 出处:网络
I have some problem with this piece of code. When I run it, I want it to NOT lock the table(s) used by the transaction. To achieve this goal I set the isolation level to ReadUncommited.

I have some problem with this piece of code. When I run it, I want it to NOT lock the table(s) used by the transaction. To achieve this goal I set the isolation level to ReadUncommited.

The problem is that it still locks the table, it acts like if the isolationLevel were Serializable. I'm using SQL server 2008

Here is the code:

using (TransactionScope scope = new Transacti开发者_如何学编程onScope(TransactionScopeOption.Required, new TransactionOptions() { IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted }))
{
   while (true)
   {
      using (SqlConnection connection = new SqlConnection(ConnectionString))
      {
         connection.Open();

         Console.WriteLine(Transaction.Current.IsolationLevel);

         SqlUtils.ExecuteNonQuery(connection, "INSERT INTO test4 (test) VALUES ('ASDASDASD')");
      }
      Thread.Sleep(1000);
   }

   scope.Complete();
}


The transaction isolation level Read Uncommitted only applies when you read data (as the name says). It will read data that's not been committed yet.

There's no way I know of to stop SQL Server from putting locks on tables when you INSERT or UPDATE data.


ReadUncommitted, like the name suggests, impacts readers - i.e. should read operations take read-locks and key-range-locks; should they respect existing locks, etc.

I wonder whether IsolationLevel.Chaos would offer anything here, but please don't use that. Please.

If your competing reader needs to see uncommitted data, then change the isolation-level of the reader. Also, it goes without saying, but long-running transactions (and DTC/LTM transactions in particular) are not recommended.

0

精彩评论

暂无评论...
验证码 换一张
取 消