Mover 300 rúpias de Asha para Ben exige duas atualizações: subtrair de uma conta e adicionar à outra. Se o sistema falhar entre eles, o dinheiro desaparece. As transações SQL existem para tornar isso impossível, tratando ambas as etapas como uma única unidade.

Neste guia, analisamos commits, reversões e falhas em uma tabela de contas pequenas. Executamos esses exemplos no SQLite e os saldos mostrados vêm dessa execução. Os comandos básicos são semelhantes entre bancos de dados, mas o comportamento de bloqueio e isolamento varia muito, por isso apontamos onde verificar a documentação do seu próprio banco de dados.

O que é uma transação?

Uma transação é uma sequência de uma ou mais instruções SQL que o banco de dados trata como uma única operação lógica. Aqui está nossa tabela:

CREATE TABLE accounts (
  id INT PRIMARY KEY,
  owner TEXT,
  balance INT CHECK (balance >= 0)
);

INSERT INTO accounts VALUES (1, 'Asha', 1000), (2, 'Ben', 200);

A restrição CHECK é uma regra de que um saldo nunca pode ficar abaixo de zero, que usaremos mais tarde. Observe que a sintaxe para iniciar uma transação varia: SQLite e PostgreSQL aceitam BEGIN, MySQL também tem START TRANSACTION e SQL Server usa BEGIN TRANSACTION.

Fora de uma transação explícita, a maioria dos bancos de dados usa autocommit, onde cada instrução é salva assim que termina. Oracle é uma exceção notável, porque uma sessão permanece em uma transação até você confirmar.

COMMIT: torne-o permanente

BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
UPDATE accounts SET balance = balance + 300 WHERE id = 2;
COMMIT;

-- Asha | 700
-- Ben  | 500

Até que COMMIT seja executado, as alterações são provisórias. Depois de retornar com sucesso, o banco de dados garante que eles foram salvos. O total em ambas as contas ficou em 1.200, que é o objetivo do exercício.

ROLLBACK: cancelar tudo

ROLLBACK desfaz tudo desde o início da transação:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT owner, balance FROM accounts;
-- Asha | 600   (visible inside this transaction)
-- Ben  | 500

ROLLBACK;
SELECT owner, balance FROM accounts;
-- Asha | 700   (back to where it was)
-- Ben  | 500

Uma reversão também acontece automaticamente se a conexão cair ou o servidor travar antes de você confirmar, portanto, uma transação pela metade não sobreviverá.

Quando uma declaração falha

Aqui está um caso mais realista. Asha tenta enviar 5.000, mas a conta não possui. O crédito para Ben é executado primeiro e depois o débito quebra a regra CHECK:

BEGIN;
UPDATE accounts SET balance = balance + 5000 WHERE id = 2;
UPDATE accounts SET balance = balance - 5000 WHERE id = 1;
-- error: CHECK constraint failed: balance >= 0

ROLLBACK;

-- Asha | 700
-- Ben  | 500

Sem a transação, Ben teria ficado com os 5.000 e os livros estariam errados. Esteja ciente de um detalhe importante: uma instrução com falha nem sempre cancela a transação por si só. No SQLite e no MySQL, por exemplo, instruções anteriores podem permanecer pendentes, então seu código precisa emitir o rollback. Em vez disso, o PostgreSQL marca toda a transação como abortada e recusa instruções adicionais até que você reverta.

No código do aplicativo, sempre emparelhe a transação com o tratamento de erros. Aqui está a ideia em Python, e nosso guia para tratamento de exceções em Python explica a sintaxe:

try:
    conn.execute("BEGIN")
    conn.execute(debit_sql, values)
    conn.execute(credit_sql, values)
    conn.execute("COMMIT")
except Exception:
    conn.execute("ROLLBACK")
    raise

Pontos de salvamento

Um savepoint marca uma posição dentro de uma transação, então você pode desfazer apenas parte do trabalho:

BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
SAVEPOINT bonus;
UPDATE accounts SET balance = balance + 999 WHERE id = 2;
ROLLBACK TO bonus;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
COMMIT;

-- Asha | 650
-- Ben  | 550

O bônus de 999 foi desfeito, enquanto o restante da transação foi continuado e comprometido. Isto é útil para etapas opcionais em um processo longo.

Propriedades ACID explicadas

A consistência é comumente mal compreendida. O banco de dados aplica apenas as regras que você declara, como restrições e chaves estrangeiras. Isso não impedirá que seu código transfira o valor errado. A durabilidade geralmente é alcançada com um log write-ahead, onde as alterações são registradas com segurança no disco antes da confirmação do commit.

O que acontece com transações simultâneas?

Abrimos duas conexões para um arquivo SQLite. O primeiro iniciou uma transação e atualizou uma linha de 1 para 2, sem fazer commit ainda. Aqui está o que a segunda conexão viu:

Connection B reads:   1                     -- no uncommitted data
Connection B writes:  database is locked    -- it has to wait
(A commits)
Connection B reads:   2                     -- now it sees the change

SQLite permite apenas um gravador por vez, o que é mais simples que bancos de dados de servidor, onde muitas transações podem escrever linhas diferentes simultaneamente. Mas o princípio é o mesmo: outras sessões não devem ver alterações não confirmadas em configurações normais, e gravações conflitantes terão que esperar. Em nosso teste, configuramos a segunda conexão para desistir imediatamente em vez de esperar, então o erro apareceu imediatamente.

Ler anomalias

Quando as transações se sobrepõem, certos problemas podem ocorrer. O padrão SQL define isso em termos do que uma transação pode observar:

Outro problema é a atualização perdida. Duas sessões lêem um saldo de 100, cada uma adiciona 10 e cada uma escreve 110. Uma atualização efetivamente desapareceu, quando a resposta deveria ser 120.

Níveis de isolamento SQL

Os níveis de isolamento permitem trocar rigor por simultaneidade. Aqui está o que o padrão SQL permite em cada nível:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

A sintaxe e o comportamento exatos dependem do seu banco de dados. Os padrões também diferem: PostgreSQL e SQL Server usam leitura confirmada, enquanto o InnoDB do MySQL usa leitura repetível. Alguns bancos de dados oferecem garantias mais fortes do que o exigido pelo padrão ou tratam um nível como outro. No PostgreSQL, por exemplo, a leitura não confirmada se comporta como a leitura confirmada. Sempre leia a documentação do seu banco de dados antes de confiar em um comportamento específico.

Impasses

Um impasse acontece quando duas transações mantêm, cada uma, um bloqueio que a outra precisa. A transação A bloqueia a linha 1 e deseja a linha 2, enquanto a transação B bloqueia a linha 2 e deseja a linha 1. Nenhuma delas pode continuar.

Bancos de dados como PostgreSQL, MySQL e SQL Server detectam isso e cancelam uma transação com erro. Esse é um comportamento normal e seu aplicativo deve estar preparado para isso. Para reduzir impasses, sempre atualize as linhas em uma ordem consistente, como primeiro o ID de conta mais baixo, mantenha as transações curtas e tente novamente quando uma delas for escolhida como vítima.

Melhores práticas

• Mantenha as transações curtas. As longas bloqueiam e bloqueiam outros usuários.
• Nunca espere por um usuário ou uma API lenta dentro de uma transação. Faça esse trabalho antes ou depois de começar.
• Sempre lide com falhas. Todo caminho deve terminar em um commit ou rollback.
• Adicione restrições. Elas fornecem ao banco de dados regras reais para serem aplicadas. Um bom design de mesa também ajuda.
• Use bons índices. Pesquisas mais rápidas significam que os bloqueios são retidos por menos tempo.
• Tenha cuidado com novas tentativas. Tente novamente em deadlocks, mas certifique-se de que uma operação não possa ser aplicada duas vezes.
• Teste a simultaneidade propositalmente. Muitos desses bugs aparecem apenas sob carga, portanto, testes de integração básicos por si só podem não revelá-los.

Considerações finais

As transações transformam várias etapas arriscadas em uma operação segura, e o ACID descreve as garantias que tornam isso confiável. Sempre que uma ação comercial afetar mais de uma linha ou tabela, pergunte-se o que aconteceria se ela parasse no meio do caminho. Se a resposta o preocupa, envolva-a em uma transação. Para praticar, abra duas sessões em um banco de dados local e tente produzir você mesmo as anomalias.

Perguntas frequentes

Continue aprendendo