Discussion :

[pbossard]

C'était plutôt entre session.update(...) ou session.save(...) et session.getTransaction().commit() que je te demandais de vérifier...

Parce que si ce n'est pas la même session, rien ne dit que le commit est fait...

entre un saveAction() et un loadAction() ultérieur, ce sont forcément 2 sessions différentes, car il s'agit de 2 actions struts différente. et qu'il n'y a pas de persistance de l'objet session au niveau Struts.

Par contre dans la partie saveAction(), c'est effectivement la même session qui est utilisée

Remarque : pour les mises à jour, je ne fais pas de session.update(...) . Je récupère l'objet, le met à jour, je fais un commit(), avant de le recharger et l'afficher (plus un commit systématique en fin de l'action struts) ; et jusqu'à preuve du contraire, je n'ai jamais eu de pb de données incorrectes à ce niveau.

[OButterlin]

Remarque : pour les mises à jour, je ne fais pas de session.update(...) . Je récupère l'objet, le met à jour, je fais un commit(), avant de le recharger et l'afficher (plus un commit systématique en fin de l'action struts) ; et jusqu'à preuve du contraire, je n'ai jamais eu de pb de données incorrectes à ce niveau.

Je ne pense pas que les données ne soient pas "persistées", le problème est plutôt "quand sont-elles persistées", et il semble bien qu'il y ait un problème ici...

D'ailleurs, ça me rappel un problème que j'ai déjà eu dans le cas d'une méthode save qui, à la fin, appelle une méthode load pour recharger (issues toutes deux du même source d'action (DispatchAction)). j'ai dû faire un session.close() entre les 2 (par contre, je ne me rappel plus quels étaient les symptômes)

Essaye peut-être ça, pour voir...

A+

[pbossard]

Ca y est,
j'ai enfin trouvé la cause de mon pb....
c'est en fait tout simple une fois qu'on a trouvé....

Je me suis rendu compte qu'il restait des transaction non fermées sur la base..
Dans certains cas, je faisait un commit, suivit plus loin d'une méthode pour récupérer une liste d'infos en base.
A l'issue du commit, la session est automatiquement fermée avec la transaction. Par conséquent le Session session = Factory.getCurrentSession() de la méthode appelée, génère une nouvelle session et une nouvelle transaction. A l'issue de la méthode, la variable "session" est détruite, mais ce n'est pas le cas de la transaction ni de la session hibernate qui reste attachée au thread tomcat.

Lors d'une action struts ultérieure, si je récupère ce thread, je retrouve également la session toujours ouverte qui y est attaché... et donc les objets hibernate correspondants, avec des données non à jour.

Je ne comprend toujours pas pourquoi même dans ce cas les refresh ou lockMode.READ n'ont pas forcé une relecture depuis la BDD, mais la chasse aux session ouvertes à résolu mon pb.

De la même façon, chaque catch() fait également un rollback de la transaction en cours, de manière à ne pas laisser de transaction en cours sur la base...

En tout cas, merci a fr1man et OButterlin pour leur aide ^__^