@Transactional envolve um método em uma transação de banco de dados: o Spring abre uma antes de o método rodar e faz commit quando ele retorna normalmente — ou faz rollback se ele lança uma exceção. Por baixo dos panos, é um proxy AOP, que é a origem da maioria das pegadinhas.
{
{
accounts.debit(from, amount);
accounts.credit(to, amount);
}
}
Por padrão, o Spring faz rollback apenas em exceções unchecked (RuntimeException) e Error — não em exceções checked. Se você lança uma exceção checked, a transação faz commit. Sobrescreva explicitamente:
@Transactional(rollbackFor = Exception.class) // roll back on checked too
public void process() throws IOException { /* ... */ }
A propagation decide o que acontece quando um método transacional chama outro:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commits independently */ }
Como o @Transactional funciona via proxy, chamar um método @Transactional a partir de outro método na mesma classe ignora o proxy — a anotação é silenciosamente ignorada. Chame entre beans, ou injete a si mesmo.
As transações são onde vive a correção dos dados, então os entrevistadores pressionam forte aqui. A regra de rollback de exceção checked e o bug de self-invocation são as duas perguntas que separam de forma confiável quem usou o @Transactional de quem o entende.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar