Discussion :

[maxime_c]

Salut a tous,

je travaille actuellement sur une appli utilisant hibernate. Pour le moment, hibernate me permet de soulager de tout le travail de requetes sql. Mais je pense que l'on doit pouvoir aller plus loin.

Par exemple, dans mon application je construit un tableau dans lequel j'insere des cellules dont les données sont récupérées dans ma base.

Ensuite, je peut sélectionner une cellule et en modifier le contenu.

Pour le moment, voila ce qui se passe:
1) je sélectionne ma cellule
2) je modifie la cellule dans ma base
et je recommence pour les autres cellules...

N'est-il pas possible grâce à hibernate de suivre un schéma du genre:
1 : initialisation de l'appli, chargements des objets métiers
2 : création / modification en travaillant en mémoire avec les objets métiers
3 : commit des objets métiers en mémoire

Merci d'avance (n'hésitez pas s'il vous faut plus d'infos).

[mOuLi]

Tu peux effectivement travailler en mémoire avec Hibernate (c-a-d sur la session Hibernate autrement appelée cache de 1er niveau) et n'impacter tes modifs qu'à la fin (en une fois). De plus ça permet de traiter tes modifs en une seule transaction (mais en fonction du contexte ça peut être un avantage ou un inconvénient)

Quand tu travailles en mise à jour avec Hibernate (delete, save, update) tu travailles d'abord en mémoire (dans la session) et c'est l'ordre de flush (ou le commit) qui va déclencher les ordres de MAJ en base de données.
A priori tu peux faire ça de 2 manières :

• [le plus simple] tu propages ta session Hibernate avec tous tes objets modifiés durant ta navigation (cf paragraphe 11.3.2. de la doc de référence Hibernate pour inspiration.
• [si jamais tu n'as pas la main sur l'ouverture/fermeture des sessions Hibernate] tu propages tes objets en cours de modification durant ta navigation ; ils seront considérés comme détachés et, lors de la validation finale (qui va lancer les MAJ), tu les "ré-attaches" à la session (par update ou merge, cf paragraphes 10.6 et 11.3.3 de la doc de référence Hibernate) pour pouvoir lancer le flush (+ commit).

Par contre, pour que l'une de ces 2 solutions puisse marcher, tu ne dois utiliser une transaction qu'à la fin de ton traitement (lors de la validation finale puisque c'est à ce moment là que vont se faire les modifs) avant ça, il ne faut surtout pas qu'il y ait de déclenchement de commit.

En général à ce genre de cas se greffe le problème du verrouillage des données (optimiste ou pessimiste) pour garantir que tes données ne sont pas modifiées par quelqu'un d'autres en même temps que toi.