Discussion :

[archer]

Salut,

Je suis entrain de développer une application web en utilisant Hibenate pour accéder à la base de données.

Le problème que je viens de rencontrer, c'est que au bout d'un certain temps, l'exception java.lang.OutOfMemoryError se génère à cause de la persistance: toutes les données de la BD se charge dans la mémoire.

Y a-t-il un moyen pour ne charger certaines tables (surtout pour les relations père fils).

Si vous avez des suggestions ou des remarque merci de me les indiquer.

[hibour]

Chaque objet que tu récupere de la BD est sauvegardé dans la Session hibernate donc faut faire des:session.clear() surtout si tu es dans une boucle apres un CRUD.

[archer]

Merci pour la réponse.

En fait j'ai certains objet que je veux garder dans les sessions du serveur web, par contre y en a d'autres dont le nombre peut atteindre des centaines de milliers que je ne veut pas charger dans la mémoire.

[OButterlin]

Tu peux utiliser session.evict(objet) si tu veux faire un traitement plus spécialisé...
Le graphe complet d'objets est obligatoire ?
Tu passes par du lazy loading ?

[archer]

J'ai pas besoin de charger le graph complet.
comment faire avec le "lazy"?

Merci

[OButterlin]

Je te propose de lire ceci pour le lazy loading.
En fonction de la version d'hibernate, le défaut peut changer.
En v2, lazy=false, en v3, lazy=true.

Maintenant, si tu charges un graphe d'objets en mémoire, tu peux à tout moment le libérer via session.evict.
Si tu utilises un cache de 2ème niveau, c'est au niveau de la factory qu'il faut jouer.
Exemple de la doc Hibernate

sessionFactory.evict(Cat.class, catId); //evict a particular Cat
sessionFactory.evict(Cat.class); //evict all Cats
sessionFactory.evictCollection("Cat.kittens", catId); //evict a particular collection of kittens
sessionFactory.evictCollection("Cat.kittens"); //evict all kitten collections

[tchize_]

mauvais plan de garder des objets hibernate dans la session serveur. En tout cas, si tu garde la session hibernate concernée ouverte. Les session hibernate ne sont pas threadsafe et intégrées à tes objets (hibernate les dérive pour y injecter la session) -> Faut protéger tous les accès à tes objets. Il vaut mieux faire une architecture un session par requete http, avec un cache de second niveau en place, ca ne surcharge pas la DB et reste performant.

[OButterlin]

mauvais plan de garder des objets hibernate dans la session serveur.

Ça c'est clair... du moins pour une application web (ce qui est le cas)...
Personnellement, je fais également une session le temps du request/response (quitte à utiliser un filtre rien que pour libérer la session en fin de cycle), ça me paraît être la meilleure pratique.

[tchize_]

je rajoute qu'a un époque, on a développé une application inter ici, qui travaillais avec une session / utilisateur, afin de pouvoir garder des objets hibernate en session scope. Au final ça a été tellement galère qu'on a tout migré pour du request scope. quitte à garder quelques objets hibernate détachés en session scope, mais sans la session hibernate Le cache de second niveau fait vraiment un bon boulot pour éviter de surcharger de requete la DB (pas qu'elle serait lente à répondre, mais on perdrait en latence réseau)

[archer]

Merci pour la réponse.

En fait il y a des choses dont vous avez parlé, et qui me paraissent importante comme la protéction de l'accès aux objets et le filtre.
Avez vous des documents ou des liens qui expliquent bien ces notions.

Merci d'avance.

[tchize_]

pour la protection, c'est la même que tu mettrais en java pour n'importe quelle donnée partagée qui doit n'être accédée que par une personne à la fois, il faut un verrou, des blocs synchronisés, ce qui implique dans un serveur web des pertes de performance assez élevées.

Pour la doc hibernante avec la session, recherche "session per request pattern hibernate" dans google, t'aura la doc, en anglais.