Transações e isolation levels: ACID sem decoreba

⏱ 15 min·⭐ 75 XP

ACID é a garantia que diferencia um banco de dados de um arquivo de texto. Atomicidade, Consistência, Isolamento, Durabilidade — não são decoreba, são propriedades com implementação concreta que você precisa entender para não introduzir bugs de concorrência sutis.

ACID: o que cada propriedade garante

-- Atomicidade: tudo ou nada
BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;  -- debita Alice
UPDATE contas SET saldo = saldo + 100 WHERE id = 2;  -- credita Bob
-- Se o segundo UPDATE falhar, o primeiro é REVERTIDO automaticamente
COMMIT;   -- ambos ou nenhum

-- Consistência: constraints são verificadas no COMMIT
BEGIN;
UPDATE contas SET saldo = saldo - 1000 WHERE id = 1;
-- CHECK (saldo >= 0) é violado → ROLLBACK automático ao tentar COMMIT
COMMIT;

-- Isolamento: transações concorrentes não se veem (depende do nível)
-- Ver seção de Isolation Levels abaixo

-- Durabilidade: após COMMIT, dado está no disco (WAL garante)
-- PostgreSQL usa Write-Ahead Log: toda mudança vai para WAL antes do heap
-- Em caso de crash, recovery reproduz o WAL
-- synchronous_commit = on (default): COMMIT espera WAL estar em disco

Isolation Levels: o trade-off consistência × performance

Nível	Dirty Read	Non-Repeatable Read	Phantom Read	Anomalias seriais
Read Uncommitted	Possível*	Possível	Possível	Possível
Read Committed (padrão PG)	Impossível	Possível	Possível	Possível
Repeatable Read	Impossível	Impossível	Impossível*	Possível
Serializable	Impossível	Impossível	Impossível	Impossível

NívelRead Uncommitted

Dirty ReadPossível*

Non-Repeatable ReadPossível

Phantom ReadPossível

Anomalias seriaisPossível

NívelRead Committed (padrão PG)

Dirty ReadImpossível

Non-Repeatable ReadPossível

Phantom ReadPossível

Anomalias seriaisPossível

NívelRepeatable Read

Dirty ReadImpossível

Non-Repeatable ReadImpossível

Phantom ReadImpossível*

Anomalias seriaisPossível

NívelSerializable

Dirty ReadImpossível

Non-Repeatable ReadImpossível

Phantom ReadImpossível

Anomalias seriaisImpossível

-- Alterar isolation level para uma transação:
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- ... operações ...
COMMIT;

-- Ou para a sessão inteira:
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- Exemplo de Non-Repeatable Read (Read Committed):
-- T1: BEGIN; SELECT saldo FROM contas WHERE id=1;  → retorna 1000
-- T2: BEGIN; UPDATE contas SET saldo=500 WHERE id=1; COMMIT;
-- T1: SELECT saldo FROM contas WHERE id=1;  → retorna 500 (mudou!)
-- Com Repeatable Read, T1 veria 1000 na segunda leitura

-- Serialization Anomaly (detectada pelo Serializable PG):
-- T1: SELECT SUM(quantidade) FROM estoque; → 100
-- T2: SELECT SUM(quantidade) FROM estoque; → 100
-- T1: INSERT INTO movimentos (tipo, qtd) VALUES ('entrada', 50) WHERE 100 < 200;
-- T2: INSERT INTO movimentos (tipo, qtd) VALUES ('saida', 100) WHERE 100 >= 50;
-- Ambas commitam — mas qualquer execução serial teria comportamento diferente!
-- Serializable aborta uma delas com: ERROR: could not serialize access

🗺️ O que cada nível de isolamento PERMITE que aconteça

	Dirty read	Non-repeatable read	Phantom read
Read Committed	Impossível	Possível	Possível
Repeatable Read	Impossível	Impossível	Possível (no padrão SQL; Postgres evita na prática)
Serializable	Impossível	Impossível	Impossível — ao custo de mais conflito e retry

Quiz rápido

O que a leitura suja significa, e qual nível de isolamento a permite?

Locking: FOR UPDATE, FOR SHARE, SKIP LOCKED

-- SELECT FOR UPDATE: lock exclusivo nas linhas (para update ou delete)
BEGIN;
SELECT id, saldo FROM contas WHERE id = 1 FOR UPDATE;
-- Agora: nenhuma outra transação pode UPDATE/DELETE/FOR UPDATE nessa linha
-- até este COMMIT/ROLLBACK
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;

-- SELECT FOR SHARE: lock compartilhado (múltiplos leitores, bloqueia writers)
-- Útil quando você lê dado que outros não devem modificar mas podem ler

-- SKIP LOCKED: ignora linhas lockadas (fila de trabalho)
-- Padrão de job queue sem conflito entre workers:
BEGIN;
SELECT id, payload
FROM jobs
WHERE status = 'pendente'
ORDER BY prioridade DESC, id
LIMIT 1
FOR UPDATE SKIP LOCKED;  -- pega o próximo não-lockado
-- ... processar job ...
UPDATE jobs SET status = 'concluido' WHERE id = $1;
COMMIT;

-- NOWAIT: falha imediatamente se não conseguir o lock
SELECT * FROM tabela WHERE id = 1 FOR UPDATE NOWAIT;
-- ERROR: could not obtain lock on row in relation "tabela"
-- Útil para detectar contention sem esperar timeout

-- Advisory locks: locks customizados no nível de aplicação
SELECT pg_advisory_lock(42);        -- lock exclusivo de id 42
-- ... operação crítica ...
SELECT pg_advisory_unlock(42);

✅

Guia prático: use Read Committed (padrão) para operações CRUD simples. Use Repeatable Read para relatórios que precisam de snapshot consistente. Use Serializable quando a lógica tem read-modify-write complexo. Use SELECT FOR UPDATE SKIP LOCKED para filas de trabalho. Nunca faça read-modify-write sem transação em sistemas concorrentes.

💡

Próximo: Normalização e modelagem — 1NF, 2NF, 3NF e quando desnormalizar intencionalmente.

Perguntas frequentes

❓ O que cada nível de isolamento evita?

Leitura confirmada evita ler dado não confirmado; leitura repetível evita o mesmo registro mudar dentro da transação; serializável evita anomalia de conjunto, como duas transações validarem a mesma condição e violarem a regra juntas. Cada nível a mais custa concorrência.

❓ Preciso de serializável?

Precisa quando a regra depende de uma condição sobre um CONJUNTO — "só pode haver um plantonista", "o saldo somado não pode ficar negativo". Nesses casos, nível mais baixo permite duas transações passarem pela verificação e violarem a regra. Fora disso, o padrão costuma bastar.

❓ Transação longa é problema?

É, e por dois motivos: ela segura recursos e, em bancos com controle de versão, impede a limpeza das versões antigas — o que incha a tabela. A regra prática é abrir transação o mais tarde e fechar o mais cedo possível, e nunca esperar por chamada externa dentro dela.

Fixando

Quiz rápido

Duas transações leem o saldo, somam e gravam. Sem cuidado, uma sobrescreve a outra. Qual mecanismo resolve mantendo concorrência?

Quiz rápido

Numa fila de trabalho em tabela, vários processos disputam as mesmas linhas pendentes. Qual recurso evita que fiquem em fila esperando uns aos outros?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

📐

Modelagem e normalização: 1NF–3NF + quando desnormalizar

SQL & Databases · 12 min · +60 XP

→

Temas deste módulo

Dados e engenharia de dados

Discussão

Carregando comentários…

Transações e isolation levels: ACID sem decoreba

⏱ 15 min·⭐ 75 XP

ACID: o que cada propriedade garante

-- Atomicidade: tudo ou nada
BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;  -- debita Alice
UPDATE contas SET saldo = saldo + 100 WHERE id = 2;  -- credita Bob
-- Se o segundo UPDATE falhar, o primeiro é REVERTIDO automaticamente
COMMIT;   -- ambos ou nenhum

-- Consistência: constraints são verificadas no COMMIT
BEGIN;
UPDATE contas SET saldo = saldo - 1000 WHERE id = 1;
-- CHECK (saldo >= 0) é violado → ROLLBACK automático ao tentar COMMIT
COMMIT;

-- Isolamento: transações concorrentes não se veem (depende do nível)
-- Ver seção de Isolation Levels abaixo

-- Durabilidade: após COMMIT, dado está no disco (WAL garante)
-- PostgreSQL usa Write-Ahead Log: toda mudança vai para WAL antes do heap
-- Em caso de crash, recovery reproduz o WAL
-- synchronous_commit = on (default): COMMIT espera WAL estar em disco

Isolation Levels: o trade-off consistência × performance

Nível	Dirty Read	Non-Repeatable Read	Phantom Read	Anomalias seriais
Read Uncommitted	Possível*	Possível	Possível	Possível
Read Committed (padrão PG)	Impossível	Possível	Possível	Possível
Repeatable Read	Impossível	Impossível	Impossível*	Possível
Serializable	Impossível	Impossível	Impossível	Impossível

NívelRead Uncommitted

Dirty ReadPossível*

Non-Repeatable ReadPossível

Phantom ReadPossível

Anomalias seriaisPossível

NívelRead Committed (padrão PG)

Dirty ReadImpossível

Non-Repeatable ReadPossível

Phantom ReadPossível

Anomalias seriaisPossível

NívelRepeatable Read

Dirty ReadImpossível

Non-Repeatable ReadImpossível

Phantom ReadImpossível*

Anomalias seriaisPossível

NívelSerializable

Dirty ReadImpossível

Non-Repeatable ReadImpossível

Phantom ReadImpossível

Anomalias seriaisImpossível

-- Alterar isolation level para uma transação:
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- ... operações ...
COMMIT;

-- Ou para a sessão inteira:
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- Exemplo de Non-Repeatable Read (Read Committed):
-- T1: BEGIN; SELECT saldo FROM contas WHERE id=1;  → retorna 1000
-- T2: BEGIN; UPDATE contas SET saldo=500 WHERE id=1; COMMIT;
-- T1: SELECT saldo FROM contas WHERE id=1;  → retorna 500 (mudou!)
-- Com Repeatable Read, T1 veria 1000 na segunda leitura

-- Serialization Anomaly (detectada pelo Serializable PG):
-- T1: SELECT SUM(quantidade) FROM estoque; → 100
-- T2: SELECT SUM(quantidade) FROM estoque; → 100
-- T1: INSERT INTO movimentos (tipo, qtd) VALUES ('entrada', 50) WHERE 100 < 200;
-- T2: INSERT INTO movimentos (tipo, qtd) VALUES ('saida', 100) WHERE 100 >= 50;
-- Ambas commitam — mas qualquer execução serial teria comportamento diferente!
-- Serializable aborta uma delas com: ERROR: could not serialize access

🗺️ O que cada nível de isolamento PERMITE que aconteça

	Dirty read	Non-repeatable read	Phantom read
Read Committed	Impossível	Possível	Possível
Repeatable Read	Impossível	Impossível	Possível (no padrão SQL; Postgres evita na prática)
Serializable	Impossível	Impossível	Impossível — ao custo de mais conflito e retry

Quiz rápido

O que a leitura suja significa, e qual nível de isolamento a permite?

Locking: FOR UPDATE, FOR SHARE, SKIP LOCKED

-- SELECT FOR UPDATE: lock exclusivo nas linhas (para update ou delete)
BEGIN;
SELECT id, saldo FROM contas WHERE id = 1 FOR UPDATE;
-- Agora: nenhuma outra transação pode UPDATE/DELETE/FOR UPDATE nessa linha
-- até este COMMIT/ROLLBACK
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;

-- SELECT FOR SHARE: lock compartilhado (múltiplos leitores, bloqueia writers)
-- Útil quando você lê dado que outros não devem modificar mas podem ler

-- SKIP LOCKED: ignora linhas lockadas (fila de trabalho)
-- Padrão de job queue sem conflito entre workers:
BEGIN;
SELECT id, payload
FROM jobs
WHERE status = 'pendente'
ORDER BY prioridade DESC, id
LIMIT 1
FOR UPDATE SKIP LOCKED;  -- pega o próximo não-lockado
-- ... processar job ...
UPDATE jobs SET status = 'concluido' WHERE id = $1;
COMMIT;

-- NOWAIT: falha imediatamente se não conseguir o lock
SELECT * FROM tabela WHERE id = 1 FOR UPDATE NOWAIT;
-- ERROR: could not obtain lock on row in relation "tabela"
-- Útil para detectar contention sem esperar timeout

-- Advisory locks: locks customizados no nível de aplicação
SELECT pg_advisory_lock(42);        -- lock exclusivo de id 42
-- ... operação crítica ...
SELECT pg_advisory_unlock(42);

✅

💡

Próximo: Normalização e modelagem — 1NF, 2NF, 3NF e quando desnormalizar intencionalmente.

Perguntas frequentes

❓ O que cada nível de isolamento evita?

❓ Preciso de serializável?

❓ Transação longa é problema?

Fixando

Quiz rápido

Duas transações leem o saldo, somam e gravam. Sem cuidado, uma sobrescreve a outra. Qual mecanismo resolve mantendo concorrência?

Quiz rápido

Numa fila de trabalho em tabela, vários processos disputam as mesmas linhas pendentes. Qual recurso evita que fiquem em fila esperando uns aos outros?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

📐

Modelagem e normalização: 1NF–3NF + quando desnormalizar

SQL & Databases · 12 min · +60 XP

→

Temas deste módulo

Dados e engenharia de dados

Discussão

Carregando comentários…