Блог

Хранимые процедуры в Cosmos DB являются транзакционными и выполняются в isolation snapshop с оптимистичным управлением параллелизмом. Это означает, что конфликты записи могут возникать, но они обнаруживаются, поэтому транзакция откатывается.

Если возникает такой конфликт, Cosmos DB автоматически повторяет хранимую процедуру или клиент получает исключение (возможно, сбой предварительного условия HTTP 412?) и ему необходимо реализовать саму логику повторных попыток?

Я попытался запустить 100 экземпляров хранимых процедур параллельно, что привело бы к конфликту записи, прочитав документ (без настройки _etag ), подождав некоторое время, а затем увеличив свойство integer в этом документе (снова без настройки _etag ).

Во всех пробных версиях до сих пор ошибок не возникало, и результат был таким, как если бы 100 запусков выполнялись последовательно. Итак, предварительный ответ таков: да, Cosmos DB автоматически повторяет запуск SP при конфликтах записи (или, возможно, обеспечивает изоляцию транзакций каким-либо другим способом, таким как блокировка), поэтому клиентам, надеюсь, не нужно беспокоиться об прерванных SP из-за конфликтов.

Было бы здорово услышать от инженера Cosmos DB, как это достигается: повторная попытка, блокировка или что-то другое?

Вы правы в том, что это нигде должным образом не задокументировано. Вот как можно выполнить проверку OCC в хранимой процедуре:

 function storedProcedureWithEtag(newItem)
{
    var context = getContext();
    var collection = context.getCollection();
    var response = context.getResponse();

    if (!newItem) {
        throw 'Missing item';
    }

    // update the item to set changed time
    newItem.ChangedTime = (new Date()).toISOString();
    var etagForOcc = newItem._etag;

    var upsertAccecpted = collection.upsertDocument(
        collection.getSelfLink(),
        newItem,
        { etag: etagForOcc },       // <-- Pass in the etag
        function (err2, feed2, options2) {
            if (err2) throw err2;

            response.setBody(newItem);
        }
    );

    if (!upsertAccecpted) {
        throw "Unable to upsert item. Id: "   newItem.id;
    }
}
  

Оценка: https://peter.intheazuresky.com/2016/12/22/documentdb-optimistic-concurrency-in-a-stored-procedure/

SDK не повторяет попытку при 412, сбои 412 связаны с оптимистичным параллелизмом, и в этих случаях вы контролируете передаваемый ETag. Ожидается, что пользователь обработает 412, прочитав последнюю версию документа, получит более новый ETag и повторит операцию с обновленным значением.

• Пример для V3 SDK
• Пример для V2 SDK