Optimistic vs Pessimistic Locking
Aprenda as duas estratégias principais para lidar com acessos simultâneos ao mesmo recurso, e quando usar cada uma.
A reserva de assento
Pessimistic Locking é como trancar a cadeira do cinema com um cadeado enquanto você decide se quer sentar ali — ninguém mais pode usar. Optimistic Locking é sentar e, na hora de confirmar, conferir se ninguém sentou antes de você. Se alguém sentou, você levanta e tenta outro lugar.
Pessimistic Locking
Você trava o recurso antes de modificá-lo, impedindo outros de acessá-lo até terminar. É seguro, mas pode causar filas de espera e reduzir a performance quando muitos usuários tentam acessar o mesmo dado.
Optimistic Locking e Versionamento
Cada registro tem um número de versão. Você lê o dado com a versão atual e, ao salvar, verifica se a versão mudou. Se mudou, alguém alterou antes de você e o sistema rejeita sua atualização. Funciona bem quando conflitos são raros.
Edição de documento com versão
Veja como optimistic locking protege a edição simultânea de um documento:
// Leitura: pega o documento com sua versão
const doc = await db.query(
'SELECT * FROM documentos WHERE id = $1', [docId]
);
// doc.version = 3
// Atualização: só salva se a versão não mudou
const result = await db.query(
`UPDATE documentos
SET conteudo = $1, version = version + 1
WHERE id = $2 AND version = $3`,
[novoConteudo, docId, doc.version]
);
if (result.rowCount === 0) {
throw new Error('Conflito! Alguém editou antes de você.');
}Quando usar cada um?
Use pessimistic locking quando conflitos são frequentes e o custo de falhar é alto (ex: transações financeiras). Use optimistic locking quando conflitos são raros e você quer máxima performance (ex: edição colaborativa, catálogos).