Обеспечение атомарности операций / транзакций в СП в Космосе

Question

У меня есть вопросы по двум различным сценариям ios.

Сценарий 1: В настоящее время мы следуем шаблону проверок запросов до и после конфликта, чтобы поддерживать состояния документов. Короче говоря, наши SP имеют следующий шаблон:

1. Проверка до конфликта - проверьте, находится ли документ A в состоянии S1.
2. Создайте документ B, который имеет переходные отношения (B зависит от A ).
3. Проверка после конфликта - проверьте, если документ A все еще находится в состоянии S1, если это не так.

Вопросы 1. Может ли документ A быть изменен после проверки после конфликта, но до совершения транзакции? Если да, каков наилучший подход для смягчения этого?

Сценарий 2: Мы хотим заблокировать наши документы, чтобы предотвратить любые изменения или разрешить частичное редактирование.

Вопросы

1. Есть ли у cosmos db какие-либо функции для реализации блокировок?
2. Можем ли мы использовать триггеры для блокировки? (поясняется ниже)

Триггеры как блокировки Мы могли бы реализовать блокировку, создав отдельный документ LOCK (поскольку все типы документов могут иметь только уникальные идентификаторы, у нас будет одна блокировка для каждого документа). Если мы хотим изменить / заменить определенный документ, у нас может быть предварительный триггер, который выполняет и проверяет блокировку.

Каковы плюсы / минусы использования триггеров для блокировки (также с точки зрения производительности)? Можно ли заменить вышеприведенный сценарий 1 , используя триггеры до и после?

Более определенно, запускается ли post-trigreged после того, как вызов Replace зафиксирован или до него ?

Answer 1

Ответы на оба ваших вопроса можно найти здесь: https://docs.microsoft.com/en-us/azure/cosmos-db/database-transactions-optimistic-concurrency.

Сценарий 1:

Мысль я не пробовал это, но для вас 1-й сценарий, я думаю, вы можете использовать Stored Procedures в Космос DB. Предполагая, что оба ваших документа находятся в одном разделе, вы передадите оба документа A и B в хранимую процедуру. Там вы создадите документ B. Как только он будет создан, вы проверите состояние A. Если A не находится в желаемом состоянии (S1), вы бы сгенерировали исключение, и это откатит всю транзакцию.

Сценарий 2:

Поскольку такие блокировки недоступны в Cosmos DB, но то, что вы пытаетесь сделать, может быть достигнуто с помощью Optimistic Concurrency в Cosmos DB. Это достигается использованием свойства _etag в документах. Параллелизм Optimisti c не позволяет автору записи случайно перезаписать изменения, сделанные другим автором в сценарии с несколькими операциями записи.