Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
APLICA-SE A: 
NoSQL
As transações de banco de dados fornecem um modelo de programação seguro e previsível para lidar com alterações simultâneas nos dados. Os bancos de dados relacionais tradicionais, como o SQL Server, permitem que você escreva a lógica de negócios usando procedimentos armazenados e gatilhos e, em seguida, envie-a ao servidor para execução diretamente no mecanismo de banco de dados.
Com bancos de dados relacionais tradicionais, você precisa lidar com duas linguagens de programação diferentes: uma linguagem de programação de aplicativo não transacional, como JavaScript, Python, C# ou Java; e uma linguagem de programação transacional, como T-SQL, que é executada nativamente pelo banco de dados.
O mecanismo de banco de dados no Azure Cosmos DB dá suporte a transações totalmente compatíveis com ACID (atomicidade, consistência, isolamento, durabilidade) com isolamento por instantâneo. Todas as operações de banco de dados dentro do escopo da partição lógica de um contêiner são executadas transacionalmente dentro do mecanismo de banco de dados hospedado pela réplica da partição. Essas operações incluem operações de gravação (atualização de um ou mais itens dentro da partição lógica) e de leitura.
A tabela a seguir lista diferentes operações e tipos de transação:
| Operação | Tipo de operação | Transação de item único ou múltiplo |
|---|---|---|
| Inserir (sem ativação antes/depois) | Escreva | Transação de item único |
| Inserir (com um gatilho pré/pós) | Escrever e ler | Transação com vários itens |
| Substituir (sem um gatilho pré/pós) | Escreva | Transação de item único |
| Substituir (por um gatilho pré/pós) | Escrever e ler | Transação com vários itens |
| Upsert (sem gatilho antes/depois) | Escreva | Transação de item único |
| Upsert (com um gatilho pré/pós) | Escrever e ler | Transação com vários itens |
| Excluir (sem um gatilho prévio ou posterior) | Escreva | Transação de item único |
| Excluir (com um gatilho antes/depois) | Escrever e ler | Transação com vários itens |
| Executar procedimento armazenado | Escrever e ler | Transação com vários itens |
| Execução iniciada pelo sistema de um procedimento de fusão | Escreva | Transação com vários itens |
| Execução iniciada pelo sistema de exclusão de itens com base na expiração (TTL) de um item | Escreva | Transação com vários itens |
| Leitura | Leitura | Transação de item único |
| Feed de alterações | Leitura | Transação com vários itens |
| Leitura paginada | Leitura | Transação com vários itens |
| Consulta paginada | Leitura | Transação com vários itens |
| Executar UDF como parte da consulta paginada | Leitura | Transação com vários itens |
Transações com vários itens
O Azure Cosmos DB permite que você escreva procedimentos armazenados, gatilhos e funções definidas pelo usuário e procedimentos de mesclagem em JavaScript. O Azure Cosmos DB dá suporte nativo à execução de JavaScript dentro de seu mecanismo de banco de dados. Você pode registrar procedimentos armazenados, gatilhos pré/pós, funções definidas pelo usuário (UDFs) e procedimentos de mesclagem em um contêiner e, posteriormente, executá-los transacionalmente no mecanismo de banco de dados do Azure Cosmos DB. Escrever a lógica do aplicativo em JavaScript permite a expressão natural do fluxo de controle, escopo de variáveis, atribuição e integração de primitivos de tratamento de exceções dentro das transações de banco de dados diretamente na linguagem JavaScript.
Os procedimentos armazenados baseados em JavaScript, triggers, UDFs e procedimentos de fusão são encapsulados numa transação ACID ambiental com isolamento de instantâneo em todos os itens dentro da partição lógica. Durante sua execução, se o programa JavaScript lançar uma exceção, toda a transação será abortada e revertida. O modelo de programação resultante é simples, mas poderoso. Os desenvolvedores JavaScript obtêm um modelo de programação durável enquanto ainda usam suas construções de linguagem familiares e primitivas de biblioteca.
A capacidade de executar JavaScript diretamente no mecanismo de banco de dados fornece desempenho e execução transacional de operações de banco de dados em relação aos itens de um contêiner. Além disso, como o mecanismo de banco de dados do Azure Cosmos DB suporta nativamente JSON e JavaScript, não há incompatibilidade de impedância entre os sistemas de tipo de um aplicativo e o banco de dados.
Controlo de concorrência otimista
O controle de simultaneidade otimista (OCC) permite evitar atualizações e exclusões perdidas. Operações simultâneas e conflitantes são submetidas ao bloqueio pessimista regular do mecanismo de banco de dados hospedado pela partição lógica proprietária do item. Quando duas operações simultâneas tentam atualizar a versão mais recente de um item dentro de uma partição lógica, uma delas vence e a outra falha. No entanto, se uma ou duas operações que tentam atualizar simultaneamente o mesmo item tiverem lido anteriormente um valor mais antigo do item, o banco de dados não saberá se o valor lido anteriormente por uma ou ambas as operações conflitantes foi realmente o valor mais recente do item.
Felizmente, essa situação pode ser detetada com o OCC antes de permitir que as duas operações entrem no limite da transação dentro do mecanismo de banco de dados. O OCC protege seus dados contra a substituição acidental de alterações feitas por outras pessoas. Também impede que outros substituam acidentalmente as suas próprias alterações.
Implementar controle de simultaneidade otimista usando cabeçalhos ETag e HTTP
Cada item armazenado em um contêiner do Azure Cosmos DB tem uma propriedade definida pelo _etag sistema. O valor do _etag é gerado e atualizado automaticamente pelo servidor toda vez que o item é atualizado.
_etag pode ser usado com o cabeçalho de solicitação fornecido if-match pelo cliente para permitir que o servidor decida se um item pode ser atualizado condicionalmente. Se o valor do if-match cabeçalho corresponder ao valor do _etag no servidor, o item será atualizado. Se o valor do cabeçalho da solicitação não estiver mais atual, o servidor rejeita a operação com uma mensagem de resposta "HTTP 412 falha de pré-condição". Em seguida, o cliente pode repesquisar o item para adquirir a versão corrente do item no servidor ou substituir a versão do item no servidor pelo seu próprio valor _etag para o item. Além disso, _etag pode ser usado com o cabeçalho if-none-match para verificar se uma nova busca de um recurso é necessária.
O valor do _etag item muda sempre que o item é atualizado. Para operações de substituição de item, if-match deve ser explicitamente expresso como parte das opções de solicitação. Para obter um exemplo, consulte o código de exemplo no GitHub. Os _etag valores são verificados implicitamente para todos os itens escritos tocados pelo procedimento armazenado. Se algum conflito for detetado, o procedimento armazenado reverte a transação e lança uma excepção. Com esse método, todas ou nenhuma gravação dentro do procedimento armazenado é aplicada atomicamente. Este é um sinal para o aplicativo para reaplicar atualizações e repetir a solicitação do cliente original.
Controle de simultaneidade otimista e distribuição global
As atualizações simultâneas de um item são submetidas ao OCC pela camada de protocolo de comunicação do Azure Cosmos DB. Para contas do Azure Cosmos DB configuradas para gravações de região única, o Azure Cosmos DB garante que a versão do lado do cliente do item que você está atualizando (ou excluindo) seja a mesma que a versão do item no contêiner do Azure Cosmos DB. Isso garante que suas escritas sejam protegidas contra serem substituídas acidentalmente pelas escritas de outras pessoas e vice-versa. Em um ambiente multiusuário, o controle de simultaneidade otimista protege você de excluir ou atualizar acidentalmente a versão errada de um item. Como tal, os itens são protegidos contra os infames problemas de "atualização perdida" ou "exclusão perdida".
Em uma conta do Azure Cosmos DB configurada com gravações de várias regiões, os dados podem ser confirmados independentemente em regiões secundárias se corresponderem _etag aos dados na região local. Depois que novos dados são confirmados localmente em uma região secundária, eles são mesclados no hub ou na região primária. Se a política de resolução de conflitos mesclar os novos dados na região do hub, esses dados serão replicados globalmente com o novo _etag. Se a política de resolução de conflitos rejeitar os novos dados, a região secundária será revertida para os dados originais e _etag.
Próximos passos
Saiba mais sobre transações de banco de dados e controle de simultaneidade otimista: