Transações e Isolamento em NewSQL

Definição

Uma transação distribuída pode alterar dados em mais de uma parte do banco preservando uma decisão comum de confirmar ou abortar. Atomicidade trata dessa unidade de resultado. Isolamento define quais efeitos de operações concorrentes podem ser observados.

No CockroachDB, escritas provisórias, registros de transação e MVCC participam dessa coordenação. O protocolo inclui otimizações próprias; descrever todo NewSQL como “um único algoritmo de commit” esconderia diferenças importantes. Referência: Transaction Layer.

Exemplo

Uma transferência debita 30 da conta A e credita 30 na conta B. Se elas estão em partes diferentes, o banco precisa decidir o resultado comum. A aplicação não deve enxergar apenas o débito como uma transação concluída com sucesso.

Serializável significa que o efeito das transações concorrentes equivale a alguma execução sequencial. Consistência externa acrescenta uma ordem compatível com a observação temporal descrita pelo sistema; o Spanner oferece essa garantia em seu modo serializável. O rótulo NewSQL, sozinho, não define o nível de isolamento. Referência: Spanner e consistência externa.

Repetição de transação

Um conflito pode provocar erro que exige repetir a transação. Repetir apenas a última instrução pode reutilizar decisões baseadas em leituras que já não são válidas.

iniciar tentativa
  ler os dados
  aplicar as regras
  escrever as alterações
  tentar confirmar
se o erro exigir retry:
  repetir a transação com limite e espera apropriados

Enviar uma cobrança externa dentro desse bloco pode duplicá-la na repetição. Efeitos externos exigem mecanismos próprios, como idempotência e outbox. Referência: erros de retry.

Aprofundamento aplicado

Resultado incerto não é erro de serialização

Um conflito conhecido pode exigir repetir a transação inteira. Uma conexão perdida durante confirmação pode deixar o resultado desconhecido. O primeiro caso permite recalcular após abortar; o segundo exige descobrir se o efeito já aconteceu antes de criar uma nova operação lógica.

operação de negócio: transferencia-42
  tentativa 1: débito + crédito + registro da operação
  resposta perdida
  retry: procura transferencia-42
  se confirmada: devolve o resultado existente

O registro de operação deve participar da atomicidade necessária e ter unicidade. Esse desenho é uma estratégia da aplicação; detalhes de erros e retries dependem do produto e do driver. Referência: retries no CockroachDB.

Exercício: separe três situações: saldo insuficiente, conflito serializável e timeout no commit. Resultado esperado: rejeitar a primeira, repetir corretamente a segunda e reconciliar a terceira, com limites de tentativas e prazo total.

Relacionado: Idempotent Operations · 3. MVCC e Isolamento na Prática.

---

Parte de NewSQL