Проверка параллелизма в объекте без обновления версии строки

Ну, что вам нужно сделать, так это проверить токен параллелизма (Timestamp) родительского объекта, когда вы пишете в дочерний объект. Единственная проблема заключается в том, что родительская метка времени отсутствует в дочерних объектах.

Вы не указали явно, но я предполагаю, что вы используете EF Core.

Глядя на https://docs.microsoft.com/en-us/ef/core/saving/concurrency, кажется, что EF Core выдаст исключение параллелизма, если UPDATE или DELETE затронет нулевые строки. Чтобы реализовать тестирование параллелизма, EF добавляет предложение WHERE, проверяющее токен параллелизма, а затем проверяет, повлияло ли обновление или удаление на правильное количество строк.

Что вы могли бы попробовать, так это добавить дополнительное предложение WHERE в UPDATE или DELETE, которое проверяет значение RowVersion родителя. Я думаю, вы могли бы сделать это, используя класс System.Diagnostics.DiagnosticListener для перехвата EF Core 2. Об этом есть статья на https://weblogs.asp.net/ricardoperes/interception-in-entity-framework-core и обсуждение на Могу ли я настроить перехватчик в EntityFramework Core?. Очевидно, что EF Core 3 (думаю, он появится в сентябре/октябре) будет включать механизм перехвата, аналогичный тому, что был в EF pre-Core, см. https://github.com/aspnet/EntityFrameworkCore/issues/15066.

Надеюсь, это будет полезно для вас.

Существует удивительно простое решение «из двух коробок», но оно требует двух модификаций, которые я не уверен, что вы можете или хотите сделать:

• Создайте представление обновляемый для дочерней таблицы, содержащей столбец ParentRowVersion
• Сопоставьте дочернюю сущность с этим представлением

Позвольте мне показать, как это работает. Все довольно просто.

Модель базы данных:

CREATE TABLE [dbo].[Parent]
(
[ID] [int] NOT NULL IDENTITY(1, 1),
[Name] [nvarchar] (50) NOT NULL,
[RowVersion] [timestamp] NOT NULL
) ON [PRIMARY]
ALTER TABLE [dbo].[Parent] ADD CONSTRAINT [PK_Parent] PRIMARY KEY CLUSTERED  ([ID]) ON [PRIMARY]

CREATE TABLE [dbo].[Child]
(
[ID] [int] NOT NULL IDENTITY(1, 1),
[Name] [nvarchar] (50) NOT NULL,
[RowVersion] [timestamp] NOT NULL,
[ParentID] [int] NOT NULL
) ON [PRIMARY]
ALTER TABLE [dbo].[Child] ADD CONSTRAINT [PK_Child] PRIMARY KEY CLUSTERED  ([ID]) ON [PRIMARY]
GO
CREATE VIEW [dbo].[ChildView]
WITH SCHEMABINDING
AS
SELECT Child.ID
, Child.Name
, Child.ParentID
, Child.RowVersion
, p.RowVersion AS ParentRowVersion
FROM dbo.Child
INNER JOIN dbo.Parent p ON p.ID = Child.ParentID

Представление можно обновлять, поскольку оно соответствует условия для обновляемых представлений Sql Server.

Данные

SET IDENTITY_INSERT [dbo].[Parent] ON
INSERT INTO [dbo].[Parent] ([ID], [Name]) VALUES (1, N'Parent1')
SET IDENTITY_INSERT [dbo].[Parent] OFF

SET IDENTITY_INSERT [dbo].[Child] ON
INSERT INTO [dbo].[Child] ([ID], [Name], [ParentID]) VALUES (1, N'Child1.1', 1)
INSERT INTO [dbo].[Child] ([ID], [Name], [ParentID]) VALUES (2, N'Child1.2', 1)
SET IDENTITY_INSERT [dbo].[Child] OFF

Модель класса

public class Parent
{
    public Parent()
    {
        Children = new HashSet<Child>();
    }
    public int ID { get; set; }
    public string Name { get; set; }
    public byte[] RowVersion { get; set; }
    public ICollection<Child> Children { get; set; }
}

public class Child
{
    public int ID { get; set; }
    public string Name { get; set; }
    public byte[] RowVersion { get; set; }

    public int ParentID { get; set; }
    public Parent Parent { get; set; }
    public byte[] ParentRowVersion { get; set; }
}

Контекст

public class TestContext : DbContext
{
    public TestContext(string connectionString) : base(connectionString){ }

    public DbSet<Parent> Parents { get; set; }
    public DbSet<Child> Children { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Parent>().Property(e => e.RowVersion).IsRowVersion();
        modelBuilder.Entity<Child>().ToTable("ChildView");
        modelBuilder.Entity<Child>().Property(e => e.ParentRowVersion).IsRowVersion();
    }
}

Объединяем

Этот фрагмент кода обновляет Child, в то время как поддельный параллельный пользователь обновляет свой Parent:

using (var db = new TestContext(connString))
{
    var child = db.Children.Find(1);

    // Fake concurrent update of parent.
    db.Database.ExecuteSqlCommand("UPDATE dbo.Parent SET Name = Name + 'x' WHERE ID = 1");
    
    child.Name = child.Name + "y";
    db.SaveChanges();
}

Теперь SaveChanges бросает нужный DbUpdateConcurrencyException. Когда обновление родителя закомментировано, дочернее обновление выполняется успешно.

Я думаю, что преимущество этого метода в том, что он практически не зависит от библиотеки доступа к данным. Все, что вам нужно, — это ORM, поддерживающий оптимистичный параллелизм. Будущий переход на EF-core не будет проблемой.

От проекта к проекту я встречаю эту проблему на широких платформах (не только .Net). С точки зрения архитектуры могу предложить несколько решений, не свойственных EntityFramework. (как по мне №2 лучше)

ОПЦИЯ 1 для реализации оптимистического подхода к блокировке. В целом идея звучит так: «Давайте обновим Клиент, а потом проверим состояние родителя». Вы уже упомянули идею «Использовать транзакцию», но оптимистичная блокировка может просто сократить время, необходимое для сохранения родительской сущности. Что-то типа:

var expectedVersion = _db.Parent...First().RowVersion;
using (var transactionScope = new TransactionScope(TransactionScopeOption.Required))
{
    //modify Client entity there
    ...
    //now make second check of Parent version
    if ( expectedVersion != _db.Parent...First().RowVersion )
        throw new Exception(...);
    _db.SaveChanges();
}

Примечание! В зависимости от настроек SQL-сервера (уровней изоляции) вам может потребоваться применить к родительскому объекту выбор для обновления, пожалуйста, посмотрите, как это сделать. Как реализовать функцию «Выбор для обновления» в EF Core

ВАРИАНТ 2 Как по мне, лучше вместо EF использовать явный SQL что-то вроде:

UPDATE 
    SET Client.BusinessValue = :someValue -- changes of client
    FROM Client, Parent
         WHERE Client.Id = :clientToChanges -- restrict updates by criteria
         AND Client.ParentId = Parent.Id -- join with Parent entity
         AND Parent.RowVersion = :expectedParent

После этого запроса в коде .Net вам нужно проверить, что была затронута ровно 1 строка (0 означает, что Parent.Rowversion был изменен)

if (_db.ExecuteSqlCommand(sql) != 1 )
    throw new Exception();

Также попробуйте проанализировать паттерн проектирования "Глобальная блокировка" с помощью дополнительной таблицы БД. Вы можете прочитать об этом подходе здесь http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html