Quelqu'un ajoute Transactional sur une méthode et cela ne semble pas fonctionner. Quelles sont les raisons habituelles ?

L'annotation est implémentée avec un proxy, donc elle ne s'applique que si l'appel passe par le bean depuis l'extérieur. Un appel depuis une autre méthode de la même classe contourne totalement le proxy, et c'est la cause la plus fréquente. Autres raisons : la méthode n'est pas publique, l'exception levée est checked et ne déclenche donc pas de rollback par défaut, le bean a été créé hors du conteneur, ou il fallait une nouvelle transaction et la propagation est restée à required.

Neuf fois sur dix c'est de l'auto-invocation. Spring enveloppe le bean dans un proxy, et la transaction démarre quand un appelant passe par ce proxy, donc si une méthode publique de la même classe appelle directement la méthode annotée, l'appel ne sort jamais de l'objet et aucune transaction ne commence. Le correctif est de déplacer la méthode dans un autre bean ou d'injecter le bean dans lui-même, et le vrai correctif est en général que la frontière était de toute façon au mauvais endroit. Ensuite je vérifie les bases : la méthode doit être publique, le bean doit être géré par Spring et non créé avec new, et la règle de rollback piège les gens parce que par défaut elle ne fait un rollback que sur les exceptions unchecked, donc une exception checked laisse commiter à moins que je précise rollbackFor. Je regarde aussi la propagation, puisqu'un traitement qui doit survivre au rollback de l'appelant a besoin de requires new, ce qui prend une deuxième connexion, et ça compte si le pool est petit. Et je garde les transactions courtes : pas d'appels HTTP, pas de publication de messages, pas d'attente sur quoi que ce soit dedans, parce que retenir une connexion à la base pendant qu'on appelle un tiers, c'est comme ça qu'un pool s'épuise.