TransactionScope и оптимистический параллелизм

Question

Я хотел бы использовать оптимистичный параллелизм с TransactionScope. Вот код, который я придумал до сих пор:

var options = new TransactionOptions {IsolationLevel = IsolationLevel.ReadCommitted}; 
using (var scope = new TransactionScope(TransactionScopeOption.Required, options)) 
{ 
    using (var connection = new SqlConnection(_connectionString)) 
    { 
     // ... execute some sql code here 

     // bump up version 
     var version = connection.ExecuteScalar<DateTime>(@" 
      DECLARE @version datetime2 = SYSUTCDATETIME(); 
      UPDATE [Something].[Test] 
       SET [Version] = @version 
       WHERE Id = @Id 
      SELECT @version 
     ", new {Id = id}); 

     // ... execute more sql code here 

     // check if version has not changed since bump up 
     // NOTE: version is global for the whole application, not per row basis 
     var newVersion = connection.ExecuteScalar<DateTime>("SELECT MAX([Version]) FROM [Something].[Test]"); 
     if (newVersion == version) scope.Complete(); // looks fine, mark as completed 
    } 
} // what about changes between scope.Complete() and this line? 

К сожалению, этот код вызывает серьезную проблему. Между проверкой версии и фиксацией транзакции могут быть некоторые изменения в базе данных. Это стандартная ошибка time of check to time of use. Единственный способ, с помощью которого я могу это решить, - выполнить проверку версии и совершить транзакцию как одну команду.

Возможно ли выполнить некоторый код SQL вместе с фиксацией транзакции с использованием TransactionScope? Если нет, то какое другое решение можно использовать?

EDIT1: Версия должна быть за приложение, а не за строку.

EDIT2: Я мог бы использовать сериализуемый уровень изоляции, но это не вариант из-за проблем с производительностью, которые могут возникнуть.

Answer 1

К сожалению, этот код вызывает серьезную проблему. Между проверкой версии и фиксацией транзакции могут быть некоторые изменения в базе данных.

Это просто неправда. Конструктор по умолчанию TransactionSope, как и в коде, который вы опубликовали, использует уровень изоляции Serializable. Хотя это, возможно, problem, он имеет побочный эффект preventing any modification to any row you queried. Это пессимистический контроль параллелизма.

Вы правы, что вам следует использовать оптимистичный контроль параллелизма. Вам необходимо использовать a TransactionScope constructor that accepts TransactionOptions и передать возможность использовать более приличный isolation level, например. читать прочитано. Что касается версии строки, используйте простой int, который вы увеличиваете с каждой записью в приложении.

UPDATE [Something].[Test] 
SET ..., [Version] = @new_version 
OUTPUT Inserted.Id 
WHERE Id = @Id AND [Version] = @old_version; 

@old_version версия, которую Вы нашли на записи при запросе его. @new_version - @old_version+1. Если строка была изменена после ее чтения, WHERE не найдет ее, и ваш результат будет пустым, поэтому вы знаете, что вам нужно читать, обновлять и повторять попытку (возник конфликт). Это a well known optimistic control scheme.

Обратите внимание, что этот оптимистичный контроль параллелизма имеет больше смысла, когда чтение и запись занимают две разные транзакции (например, читать в T1, отображать пользовательскую форму, а затем записывать в T2). Когда чтение и запись происходят в той же транзакции, тогда лучше оставить его на движке. Я бы просто использовал snapshot isolation level, который решает проблему из коробки.