Vamos a um exemplo para ficar mais claro:

1. A transação A estava alterando a nota da prova de matemática de um aluno, mudando de nota 8 para nota 8,5...
2. Antes de esta transação A terminar, outra transação B estava lendo as notas das provas de matemática de todos os alunos e gravando a nota média das provas no banco de dados...
3. Ainda, uma terceira transação estava lendo a nota média das provas de matemática que a transação B estava atualizando...
4. Neste momento, a transação A falha, e a atualização na nota é cancelada, revertendo o valor da nota daquele aluno para 8.
5. A transação B é ordenada então para que seja cancelada, e a média das notas não é salva.
6. Como consequência dos efeitos em cascata, a transação C que iria ler a média das notas também deve ser cancelada.
7. Dessa forma, observamos que um erro na transação A fez cancelar a transação B que lia um dado alterado por A, e a transação C foi cancelada porque lia um dado afetado pela transação B que foi cancelada também. Isso é o efeito em cascata.

É fácil entender que o rollback em cascata pode ser muito complexo e demorado. Por isso que quase todos os mecanismos de recuperação são projetados de modo que o rollback em cascata nunca seja necessário.

Na prática, o rollback em cascata das transações nunca é exigido nos SGBDs modernos, porque os métodos de recuperação atuais garantem sequenciamento das transações sem cascata. Logo, não é necessário gravar quaisquer operações de leitura de dados (read_item) no log, pois estas só seriam necessárias para determinar o rollback em cascata.