Comportement étrange de Hibernate avec le persist au sein d'une transaction

J'étudie Hibernate et je réalise des petits TP. Actuellement j'en suis à essayer de comprendre la différence entre persist et save. Si j'ai bien compris, le persist n'affecte pas forcéement immédiatement un id à l'objet à persister mais surtout il est défini dans le cadre d'une transaction.

Or quand j'exécute le code suivant, j'ai mon objet qui est persisté quoi qu'il arrive. Y a-t-il quelque chose que je n'aurais pas comprise :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class MainApp {   @Transactional public static void main(String[] args) { Session session = HibernateUtil.getSessionFactory().openSession(); session.beginTransaction();   Imagerie imagerie = new Imagerie(); imagerie.setNom("toto"); session.save(imagerie); session.flush(); if (1 == 1) { // On lève une exception avant le commit et à l'intérieur d'une transaction throw new NullPointerException(""); } session.getTransaction().commit(); // ce code est inatteignable // L'entité "Imagerie" est tout de même persistée en base ! } }

---

Bonjour.
Si tu enlèves "session.flush();" que se passe-t-il ?

Code:

---

1 2 3 4 5

public void flush() throws HibernateException Force this session to flush. Must be called at the end of a unit of work, before commiting the transaction and closing the session (depending on flush-mode, Transaction.commit() calls this method). Flushing is the process of synchronizing the underlying persistent store with persistable state held in memory.

---

@Transactional sur la méthode main, static, vraiment ? ^^

@Transactional est un marqueur à appliquer sur les méthodes d'un service Spring. Il permet à spring d'injecter le code nécessaire pour démarrer, et commiter ou rollbacker une transaction, à l'entrée et à la sortie d'une méthode. Il n'aura strictement aucun effet sur tout ce qui n'est pas managé par Spring, et donc, a fortiori, sur aucune méthode static (même si elle faisait partie d'un bean spring).

De plus, dès qu'on met @Transactional, on entre dans un mode de gestion des transactions déclaratif (par opposition à la gestion impérative). Et donc, il ne servira à plus rien (et même, il est contre-productif voir complètement faux) de gérer les transactions manuellement (plus aucun call à session.beginTransaction).

Pour finir, dans une gestion impérative des transactions, il est de la responsabilité du programmeur de rollbacker la transaction en cas d'erreur: donc, il faut un bloc catch qui implémente un rollback de la transaction.