Hier petite decouverte en me plongeant dans les transactions, spring et hibernate.

1er découverte : lorsque l'on travaille avec les transactions par Spring, il est important de gérer les ouvertures de transaction en un seul point sur l'arbre d'execution. Je m'explique si vous mettez l'annotation @transaction(readOnly=true) sur une methode A et que celle-ci appelle la methode B qui elle change un parametre sur les transactions @transactional(propagation.Mandatory). Au moment ou l'on passe dans la methode B la transaction prend le paramètre de propagation et repasse tout les autres dans leurs valeurs par défaut. Nous perdons donc le readOnly=true, la valeur par défaut étant readWrite.

2e découverte : La sémantique du readOnly pour les transactions n'est pas obligatoirement ce que l'on croit. Et oui celui-ci ne represente en fait que le passage dans une politique optimisant les flushs dans le cadre de la lecture. Une ecriture sur une transaction readOnly va donc passer avec Hibernate ( attention cela semble ne pas être le cas avec tout les ORM et particulièrement TopLink ).