Discussion :

[romainw]

Bonjour,

Je travaille sur un projet avec une couche services JBoss EJB3 et hibernate pour la persistence. C'est JBoss qui gère mes transactions Hibernate.

J'ai du mal à comprendre un phénomène qui se produit sur la suppression d'un objet dont dépendent plusieurs objets par foreign key :

1/ Si je supprime avec Hibernate comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HibernateUtils.getCurrentSession().delete(entity);

Je récupère une org.hibernate.exception.ConstraintViolationException qu'une fois sorti de mon service (dans le front).

2/ Si je fais ma suppression en HQL, l'exception est jetée juste après le executeUpdate() (je peux donc la catcher dans mon service) et la transaction rollback bien.

J'essaie de comprendre pourquoi je n'ai pas le même comportement dans les 2 cas. Pour moi l'explication est qu'Hibernate fait un flush de la session juste après un executeUpdate(), mais seulement à la fin du service sur un delete hibernate.

[ohanny]

Effectivement, suite à une requête HQL, Hibernate génère tout de suite la requête SQL correspondante, et donc un flush() est effectué (pour assurer la synchronisation entre la bdd et les objets persistants Java), alors que session.delete() est mis en attente et la requête SQL correspondante est exécutée au plus tard juste avant la fin de la transaction.

[romainw]

Bon ben finalement je catch mes SQLException dans mon business delegate et je m'en sors avec les errorCode. Un peu crado mais je vois pas comment faire autrement pour l'instant...

Sinon en lisant la doc Hibernate :

If you work in a CMT environment, you might also want to use the same entity manager in different parts of your code. Typically, in a non-managed environment you would use a ThreadLocal variable to hold the entity manager, but a single EJB request might execute in different threads (e.g. session bean calling another session bean). The EJB3 container takes care of the persistence context propagation for you. Either using injection or lookup, the EJB3 container will return an entity manager with the same persistence context bound to the JTA context if any, or create a new one and bind it (see Section 1.2.4, “Persistence context propagation” .)

Our entity manager/transaction management idiom for CMT and EJB3 container-use is reduced to this:

//CMT idiom through injection
@PersistenceContext(name="sample") EntityManager em;

In other words, all you have to do in a managed environment is to inject the EntityManager, do your data access work, and leave the rest to the container. Transaction boundaries are set declaratively in the annotations or deployment descriptors of your session beans. The lifecycle of the entity manager and persistence context is completely managed by the container.

Je ne comprends pas trop le sens, car pour mes opérations de persistence côté back je passe par la session hibernate obtenue comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new AnnotationConfiguration().configure().buildSessionFactory().getCurrentSession();

[ohanny]

tu peux aussi ajouter une lecture de vérification dans ta règle métier avant de demander le delete et renvoyer alors une exception applicative appropriée