APRENDER. PRATICAR. EVOLUIR.Uma instrução falhada não define toda a unidade
O laboratório altera 50 para 60 dentro de uma transação e tenta inserir um token já existente numa coluna UNIQUE. Com a política ABORT por omissão, o INSERT falha, mas a transação continua ativa: a própria ligação lê 60 e outra lê 50. O guião executa ROLLBACK e confirma que o valor externo permanece 50. Numa segunda sequência, INSERT OR ROLLBACK termina a transação quando encontra o conflito. O código de restrição é o mesmo, mas a política e o destino das alterações anteriores diferem. Num lote fictício cujos dois passos são indivisíveis, confirmar a alteração anterior após capturar a exceção viola o contrato. O teste precisa de conferir o estado final e a resposta ao consumidor.
Checkpoint incompleto com chamada bem-sucedida
Noutra sequência, A mantém uma leitura de 50 enquanto B confirma 51, 52 e 53. O checkpoint PASSIVE devolve estado zero, mas copia menos páginas do que as existentes no WAL. A leitura antiga continua a observar 50 e a nova vê 53. Após terminar a leitura antiga, TRUNCATE devolve [0,0,0] e uma nova consulta mantém 53. O ensaio demonstra a diferença entre terminar a chamada e concluir todo o trabalho. Guarda os três campos e o estado das transações; não reduzas a observação a sucesso ou erro. O guião desativa checkpoints automáticos apenas para controlar esta sequência. Não é recomendação de configuração universal, nem autorização para remover um WAL em utilização para libertar espaço.
Traduzir mecanismo em condições de aceitação
Imagina um fornecedor que entrega um patch após os testes locais, mas cujo destino usa outro motor e um gestor transacional. A revisão deve listar o que falta: regras do driver real, falha entre passos, repetição com dados alterados, duração de reservas e leitores prolongados. Define para cada condição o estado final esperado e a evidência a recolher. Acrescenta critérios de paragem, recuperação e responsável pela decisão. Se o cut-off não permitir o ensaio, uma serialização temporária dos jobs pode ser avaliada com custo, prazo e risco explícitos. O sucesso de um lote sob workaround não demonstra correção definitiva. A pressão do calendário informa a decisão de risco, mas não substitui a observação dos percursos que falharam.
Passagem operacional e aprendizagem verificável
Num postmortem fictício, separa a escrita mantida durante uma chamada externa, a ausência de teste com concorrência e a mensagem que ocultava códigos distintos. São fatores relacionados, mas cada ação precisa de dono e resultado próprio. Um campo de log entregue melhora diagnóstico; não prova que a transação encurtou. Um teste novo executado precisa de mostrar que distingue a versão defeituosa da corrigida. Para RUN, prepara um guia com condições de aplicação, limites de repetição, estado a verificar e destino de escalada. A oficina proposta pede aos participantes que expliquem estes limites em inglês ao fornecedor e registem a decisão. O guião existe, mas não houve sessão humana nem revisão independente de especialista; essas evidências continuam por obter.
python3 content/labs/problem-transactions/run.py --output /tmp/dr-problem-atomicity.json
# Compare: abortOnlyFailedStatement / explicitRollbackOfUnit
# Compare: readerLimitsCheckpoint / checkpointAfterReaderEnds
# Check final state, not only whether the call raised an exception.Um INSERT rejeitado deixa um UPDATE anterior pendente; um checkpoint PASSIVE pode terminar com estado zero e ainda ter páginas por copiar.
Armadilhas comuns
Confundir exceção com rollback total, chamada sem erro com trabalho integral concluído ou checkpoint local com recuperação após falha de energia.
Tópicos relacionados: Risco residual e workarounds · Passagem para RUN e prevenção
Aceita a correção pelo estado funcional e pelos limites operacionais observados, incluindo falhas entre passos e leitores prolongados.
Referência: The ON CONFLICT Clause · Problem management practices 2026-09; ServiceNow Brazil examples with scoped plugins and properties