8.1. Transações, ACID e isolamento fraco
ACID simplifica erros e concorrência; read committed e snapshot isolation evitam muitos, mas não todos, os bugs.
Resumo
- Atomicidade: abortar desfaz tudo. Consistência: invariantes do app. Isolamento: sem interferência. Durabilidade: não perde o confirmado.
- Transação multi-objeto mantém dados relacionados em acordo (ex.: contador de não lidos + mensagem).
- Read committed: sem dirty read (ler não confirmado) e sem dirty write (sobrescrever não confirmado).
- Snapshot isolation: cada transação lê um retrato fixo do banco, via MVCC. Ideal para backups e leituras longas.
- Em vários bancos, "repeatable read" é na verdade snapshot isolation: os nomes dos níveis variam e confundem.
Perguntas-chave
responda de cabeça, depois abraO que o C de ACID realmente significa?
Que a aplicação mantém suas invariantes; é propriedade da aplicação, que usa A, I e D do banco para consegui-la.
O que é MVCC?
Multi-version concurrency control: o banco guarda várias versões de cada linha e cada transação vê as versões válidas no seu snapshot.
Que anomalia o read committed ainda permite?
Read skew: ler partes do banco em momentos diferentes, vendo um estado que nunca existiu (ex.: soma de duas contas errada durante uma transferência).
Exercícios de fixação
0/5 respondidas1.
Uma transferência debita a conta A, o servidor cai antes de creditar B, e o banco desfaz o débito. Qual propriedade agiu?
2.
Um backup de 3 horas lê o banco enquanto ele recebe escritas. Qual nível evita um backup inconsistente?
3.
A transação T1 atualiza um saldo e ainda não confirmou; T2 lê esse saldo novo. Isso é:
4.
Segundo o livro, quem garante a "consistência" do ACID?
5.
No PostgreSQL, o nível chamado
REPEATABLE READ implementa na prática: