javax.persistence.RollbackException: Transaction marked as rollbackOnly

Bonjour,

J'ai migré une appli de vieilles librairies à des librairies un peu plus à jour.
J'ai un souci quand je veux supprimer une ligne dans une table (toute simple sans clé étrangère ou autre).

Je finis dans GenericJpaDAO.jabva par appeler (comme avant) :

Code:

---

1 2 3 4 5 6 7

public void deleteObject(Object object) { try { em.remove(object); } catch (Exception e) { em.remove(em.merge(object)); } }

---

Dans le service

Code:

---

1 2 3

public void deleteMySpecificObject(MySpecificObject obj) { myDAO.deleteObject(obj); }

---

Au cas où ça serve, comme avant le service est déclaré comme tel :

Code:

---

1 2 3 4

@Transactional(rollbackFor = Throwable.class, propagation = Propagation.REQUIRED) public class MyService implements IMysService { ... }

---

J'arrive pas à trouver de solution pour comprendre ce qui provoque ça.
L'insertion d'une nouvelle ligne fonctionne bien et sa modification également, mais la suppression ne marche plus...

EDIT : si je remplace par em.remove(object); par em.remove(em.merge(object)); --> ça marche de nouveau.
Autrement dit mon Exception n'était pas catchée et donc maintenant la fonction remove ne marche plus tant qu'un merge n'est pas fait avant.
-->si quelqu'un peu m'expliquer car je ne suis pas très confiant d'avoir du flou dans ma couche bas niveau...

Merci.

Bonjour,
D'après ce que je comprends, le changement de comportement n'est pas lié directement avec Spring mais plutôt avec JPA/Hibernate. La différence entre em.remove() et em.remove(em.merge()) tient dans la gestion du statut de l'objet dans la session Hibernate.

Voici un petit lien qui explique les différents statuts de session hibernate.

La fonction "merge" sert, comme son nom l'indique, à fusionner l'objet entité qui se trouve en session Hibernate et l'objet entité qui se trouve en statut "detached". La base est également mise à jour pour refléter le changement effectué dans la session Hibernate. On peut dire que "merge" effectue la fusion puis un appel à "update".
Dans votre exemple, il me semble que l'entité donné à la méthode de persistance est en statut "detached". Hibernate mentionne donc par une Exception que l'objet n'est pas attaché à la session et qu'il ne peut donc pas le supprimer. Chose que vous avez "cachée" dans la directive catch derrière l'appel à "merge" qui réinsère l'objet en session.

Un petit conseil toutefois, vous devriez de préférence effectuer un code comme ceci :

Code:

---

1 2	MyObject entity = em.find(MyObject.class, object.getPrimaryKey()); em.remove(entity);

---

Ce code devrait faire la même chose, sauf qu'à la place de "merge" en session Hibernate l'objet (processus lent, notamment à cause des vérifications de type "stale-checks"), il va rechercher par clé primaire l'objet en session Hibernate (rapide) puis faire le remove (à faire dans tous les cas). Le code ne nécessite également pas de try-catch, processus à nouveau relativement lent (quoique généralement négligeable en comparaison des accès à la DB).

Il se peut que les librairies Hibernate ait légèrement changé de comportement au fil du temps et qu'auparavant la fonction "remove" acceptait la suppression des entités en statut detached. Ou alors que pour une raison quelconque lié à votre migration, l'entité est maintenant en statut "detached" alors que ce n'était pas le cas auparavant.

En espérant ne pas m'être trompé dans l'analyse en fonction des informations fournies (ce qui précède n'est qu'une supposition qui pourrait être confirmée si le code que je propose par "find" puis "remove" remplace effectivement le code "remove(merge)").

OK merci.

Concrètement, cela donne quoi pour ma fonction générique deleteObject car le getPrimaryKey n'existe pas pour un objet

Code:

---

1 2 3 4

public void deleteObject(Object object) { Object entity = em.find(object.getClass(), object.getPrimaryKey()); em.remove(entity); }

---

Dans ton code il te faut remplacer "object.getPrimaryKey()" par le getter de ta clé primaire (simple ou composite). Si tu veux une méthode aussi générique que "remove(Object o)", tu vas devoir créer une interface (ou une classe abstraite) permettant d'accéder de manière générique à ta clé primaire.
Par exemple si ta clé primaire est un attribut long nommé "id", tu as probabablement un getter getId() sur tous tes entités. Dans ce cas, crée une interface IEntity qui contient simplement les getter/setter getId() et setId(). Fais en sorte que tes entités implémentent cette interface. Ton code devient alors :

Code:

---

1 2 3 4 5 6 7

public void deleteObject(IEntity entity) { IEntity e = (IEntity) em.find(entity.getClass(), entity.getId()); if(e != null) em.remove(e); else // peut être throw(IllegalStateException) si tu souhaites être averti d'une éventuelle tentative pour supprimer un entité qui n'existe pas. }

---

Hum, ça me paraît pas très générique : il faudrait que tous les objets aient une clé qui s'appelle "id", sans compter les PK composites.

Je vais donc rester sur em.remove(em.merge(object));

Rien n'empêche de mettre une fonction getId() plus générique avec une interface comme ceci :

Code:

---

Object getId();

---

et dans une entité où la clé primaire serait composite et nommé "compositePrimaryKey" :

Code:

---

1 2 3 4

@Override Object getId(){ return this.getCompositePrimaryKey(); }

---

je donnais l'exemple de la clé primaire de type "long" car c'est le type le plus couramment utilisé.

OK, why not.

Je laisse les autres faire leur choix.
Moi si ça marche je m'évite du code en plus ;-)

Merci en tous cas.

Citation:

---

Envoyé par Lordsephiroth

Rien n'empêche de mettre une fonction getId() plus générique avec une interface comme ceci :

Code:

---

Object getId();

---

et dans une entité où la clé primaire serait composite et nommé "compositePrimaryKey" :

Code:

---

1 2 3 4

@Override Object getId(){ return this.getCompositePrimaryKey(); }

---

je donnais l'exemple de la clé primaire de type "long" car c'est le type le plus couramment utilisé.

---

Object !!! haaa!!! hérétique,au bucher !!! :P

Type générique serai un poil plus sympa quand même.

Code:

---

1 2 3 4

public interface Entity<T> { T getId(); }

---

Tu peut même pousser le vice a

Code:

---

<T extend Serializable>

---

.

Citation:

---

Envoyé par bilgetz

Object !!! haaa!!! hérétique,au bucher !!! :P

---

J'avoue... la solution en utilisant un type générique T est bien meilleure que Object.
Je m'en vais de ce pas me fouetter !