@Transactional enveloppe une méthode dans une transaction de base de données : Spring en ouvre une avant l'exécution de la méthode et commit lorsqu'elle se termine normalement — ou effectue un rollback si elle lève une exception. Sous le capot, c'est un proxy AOP, source de la plupart des pièges.
{
{
accounts.debit(from, amount);
accounts.credit(to, amount);
}
}
Par défaut, Spring n'effectue un rollback que sur les exceptions unchecked (RuntimeException) et Error — pas sur les exceptions checked. Si vous levez une exception checked, la transaction commit. Surchargez ce comportement explicitement :
@Transactional(rollbackFor = Exception.class) // rollback aussi sur les checked
public void process() throws IOException { /* ... */ }
La propagation décide de ce qui se passe quand une méthode transactionnelle en appelle une autre :
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commit indépendamment */ }
Comme @Transactional fonctionne via un proxy, appeler une méthode @Transactional depuis une autre méthode de la même classe contourne le proxy — l'annotation est silencieusement ignorée. Appelez entre beans, ou injectez self.
Les transactions sont le siège de la justesse des données, aussi les recruteurs insistent-ils ici. La règle de rollback sur exception checked et le bug de l'auto-invocation sont les deux questions qui séparent de façon fiable ceux qui ont utilisé @Transactional de ceux qui le comprennent.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don