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

Ответ 1

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

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

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

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

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-ядро не будет проблемой.

Ответ 2

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

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

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

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

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

Ответ 3

От проекта к проекту я сталкиваюсь с этой проблемой на широких платформах (не только .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.SaveChanges() != 1 )
    throw new Exception();

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