Spring + hibernate + sessionInViewFilter : problème d'autogoal avec flush

Bonjour,

Continuant mon apprentissage de spring et hibernate, j'ai découvert un truc qui m'a passablement effrayé:

Un objet attaché à une session hibernate se sauve automatiquement lorsque la session est flushé. Mon problème c'est que souvent, il arrive que je commence à modifier un objet que j'ai au préalable chargé puis qu'entre temps je fasse appel à d'autres méthodes DAO (par ex. pour des tests), dont certaines contiennent des find qui peuvent déclencher un flush.

Si cela arrive, hibernate essaie de sauver un objet que j'ai pas fini de retoucher, déclenchant des problèmes de not null etc....

Le rêve serait que hibernate ne fasse jamais d'update sans que je le demande explicitement mais d'après le forum d'hibernate c'est impossible, celui qui a demandé ça s'est limite fait insulté par des intégristes.

Eventuellement, j'arriverai à maitriser le problème entre ma couche business et les couches DAO inférieures. Mais par contre, si l'entité est manipulée par l'UI et que l'UI fait un appel à une classe business pendant qu'elle est en train de bricoler avec, ça va poser problème.

J'utilise un sessionInViewFilter fourni par Spring, j'ai pensé que mettre singleSession à false pourrait peut être aidé et me permettre d'avoir des sessions par transaction applicative (Un appel vers une classe business = une session) mais je suis pas sûr des effets de bord.

Est-ce une bonne solution? Quelqu'un pourrait m'éclairer un peu sur le sujet? Ce serait cool merci.

Le problème ne vient pas d'Hibernate mais de la façon dont tu gères tes sessions / transaction.
Si tu ne commit pas ta transaction ou ne demandes pas un flush explicite, Hibernate ne le fera pas.

Citation:

---

Le problème ne vient pas d'Hibernate mais de la façon dont tu gères tes sessions / transaction.

---

C'est vrai, néanmoins ça me préoccupe.

Citation:

---

Si tu ne commit pas ta transaction ou ne demandes pas un flush explicite, Hibernate ne le fera pas.

---

Si justement....
Certaines opérations faites avec la session déclenchent automatiquement un flush. Et dans ce flush sont pris les changements même partiels effectués sur les entités.

Citation:

---

Envoyé par _skip

C'est vrai, néanmoins ça me préoccupe.



Si justement....
Certaines opérations faites avec la session déclenchent automatiquement un flush. Et dans ce flush sont pris les changements même partiels effectués sur les entités.

---

Peut être que ce sujet pourra t'intéresser

http://forum.springframework.org/arc...p/t-11200.html

Mais j'ai une question, tu gères manuellement tes session ou passes tu par getHibernateTemplate ?

- soit tu gères l'ordre de tes instructions (si possible) pour éviter de déclencher le flush
- soit tu utilises le setFlushMode sur la session (voir paragraphe sur le flush dans la doc), pour que le flush ne se produise qu'au commit de ta transaction, ou par appel explicite à la méthode flush.

la gestion manuelle est déconseillé à mon avis ca donne du code sale et c'est difficile à maintenir pour ceux qui ne connaissent pas la séquence par coeur

l'utilisation du transaction manager avec la définition de la propagation doit à mon avis résoudre 99,9 % des cas (ou de l utilisation de l'annotation driven) le tout couplé à HibernateTemplate et OpenSessionInViewFilter


je comprend pas l utilisation d un flush pour des find ... si tu vas au supermarché tu vas payé pour le prix posé sur l étiquette non pas celui est définit en coulisse par le management il y a que des cas d utilisation très critique comme celui d un site de vente aux enchères mais je pense pas que ca cadre avec les besoins de tes clients ...

Merci à vous 2,

Dans le comportement par défaut d'hibernate si j'ai bien compris la doc, un flush de session est effectué *automatiquement* avant les opérations de recherches et de bulkupdate afin de s'assurer que ces dernières ne prendront pas en compte des données qui sont censées ne plus exister ou avoir été modifiées par du précédent code.

C'est ce qui fait, que, tranquillement en train de modifier mon entité, j'ai soudainement fait un appel vers une classe DAO qui a déclenché un flush sans que je le demande, et vu que j'avais encore des choses à faire sur l'entité avant de la sauvegarder (2 lignes plus bas) ça m'a fait une violation d'intégrité.

PS: J'ai utilisé le paramètre singleSession=false dans le Filtre spring et ça fait ce que je demande. Ca ne change rien au fait que je trouve cette *magie* de sauvegarde automatique des entités changées affreusement mal venue et bien plus sujette à déclencher des situations inattendues qu'à amener quoi que ce soit de bon. J'ai encore cherché toute la soirée comment désactiver ça, sans succès.

Citation:

---

Envoyé par _skip

PS: J'ai utilisé le paramètre singleSession=false dans le Filtre spring et ça fait ce que je demande. Ca ne change rien au fait que je trouve cette *magie* de sauvegarde automatique des entités changées affreusement mal venue et bien plus sujette à déclencher des situations inattendues qu'à amener quoi que ce soit de bon. J'ai encore cherché toute la soirée comment désactiver ça, sans succès.

---

c'est votre méthodologie de modification des entités qui est "erronée"…

essayez de voir une méthode qui met à jour les champs d'un POJO comme une routine de noyau qui bloque les interruptions : ça doit être le plus court possible…

tout ce qui est nécessaire à la modification des champs doit avoir été collecté avant de commencer…
et une fois les modifications commencées, il faut éviter tout round-trip vers le repository…

Citation:

---

tout ce qui est nécessaire à la modification des champs doit avoir été collecté avant de commencer…
et une fois les modifications commencées, il faut éviter tout round-trip vers le repository…

---

Oui c'est vers cela que je me tourne au vu de ces récentes découvertes.

Ca veut aussi dire que c'est pas tant bien que je laisse l'UI avoir accès à des objets managés par hibernate si j'extrapole.
Du temps ou je bossais avec .Net j'ai toujours utilisé une business façade et des entités déconnectées. Je sais pas pourquoi je me suis mis dans la tête avec hibernate de faire du full OO en profitant du lazy loading et tout ça...

Citation:

---

Envoyé par _skip

Oui c'est vers cela que je me tourne au vu de ces récentes découvertes.

Ca veut aussi dire que c'est pas tant bien que je laisse l'UI avoir accès à des objets managés par hibernate si j'extrapole.
Du temps ou je bossais avec .Net j'ai toujours utilisé une business façade et des entités déconnectées. Je sais pas pourquoi je me suis mis dans la tête avec hibernate de faire du full OO en profitant du lazy loading et tout ça...

---

ca me semble vraiment bizzard les problèmes que tu rencontres, bien sur qu'avec jsf / icefaces - spring - hibernate tu peux faire du full oo

montre voir un peu de code jsf, managed bean, business service et dao que tu utilises