Hibernate et gestion de la mémoire cache niveau 1

Bonjour à tous,

je suis en train de travailler sur un projet utilisant Hibernate, et plus précisément sur une fonction pouvant traiter un grand nombre de données (typiquement un ensemble de clients desquels on récupère les commandes, desquelles on récupère les lignes commande et desquelles on récupère les produits).

Cette fonction de recherche fonctionne parfaitement avec des critères de sélection très précis mais déclenche des exceptions "OutOfMemory : Java Heap Space" dès que les critères deviennent trop vagues (par exemple recherche uniquement sur le nom du client, au lieu de son identifiant).

J'ai donné plus de mémoire à Tomcat en configurant l'option JAVA_OPTS dans le script de lancement Catalina.bat (travaillant sous Windows) ce qui a permis d'effectuer des recherches un peu plus grosses, sans pour autant permettre des recherches réellement importantes.

J'essaye donc de travailler sur le cache de niveau 1 de Hibernate, en supprimant les objets dont je n'aurai plus besoin dans la suite de la fonction.

Voici un exemple de code que j'utilise pour supprimer ces objets :

Code:

---

1 2 3

// on supprime la commande du cache de la session Hibernate courante afin de gagner de la mémoire this.sessionHibernate.evict(commande);

---

J'ai vérifié si la session Hibernate ne contenait plus mon objet après la suppression à l'aide de :

Code:

---

1 2 3 4

if(this.sessionHibernate.contains(commande)) { System.out.println("OK"); }

---

...et le retour est concluant : l'objet ne se trouve plus dans la session.

Pourtant malgré tout cela, la mémoire attribuée à Tomcat continue d'augmenter et ne se stabilise pas comme je l'aurai pensé, et continue donc de me donner ces satanées erreurs...

Ai-je oublié quelque chose ? Est-ce normal (non, clairement) ? Y a-t-il un autre moyen de faire ?

Merci par avance pour vos réponses,
MiniMarch

Bonjour,
La meilleure chose à faire, à mon avis, c'est d'utiliser une requête HQL optimisée, avec inner join et autres, afin de charger le graphe d'objets suivant les critères indiqués. Je crois que ce serait difficile de s'en sortir en ajoutant juste de la mémoire à Tomcat, si ça se trouve que les requêtes générées automatiquement par hibernate créent des problèmes de produit cartésien ou n+1 select ...
Pense donc d'abord à optimiser la requête avant de chercher à controler le cache.

De part d'autres problèmes techniques (voir http://www.developpez.net/forums/sho....php?t=395107), la fonction de recherche ne se base pas sur une seule requête mais sur un ensemble de requêtes chargeant progressivement les informations lorsque la fonction en a besoin.

J'effectue donc effectivement un grand nombre de requêtes (je pense d'ailleurs être tombés dans ce problème de N+1 selects, mais je ne vois pas comment en sortir).

De plus les critères de recherches peuvent variables (il peut s'agir d'une recherche sur le nom, le prénom, ou sur la détention d'un produit particulier...), et j'utilise donc Criteria pour effectuer la recherche. Au final je n'ai donc que très peu la main sur la requête SQL finale... d'où mes recherches vers les problèmes de cache.

Citation:

---

Envoyé par minimarch76

Cette fonction de recherche fonctionne parfaitement avec des critères de sélection très précis mais déclenche des exceptions "OutOfMemory : Java Heap Space" dès que les critères deviennent trop vagues (par exemple recherche uniquement sur le nom du client, au lieu de son identifiant).

---

Peut-être qu'il faudrait dans ce cas faire deux requêtes, une première pour récupérer d'abord le client et une deuxième pour les commandes du client à partir de l'id de l'objet retourné premièrement ...
D'autre part, pour ce genre de requêtes multi-critères où tu as besoin d'un certain contrôle sur le SQL envoyé à la base de données, moi pencherais plutôt à ne pas utiliser Hibernate, à moins peut-être de passer par SQLQuery où tu peux écrire ta requête SQL directement, mais ceci retire la gestion simple des multiples critères que permet Criteria.
Ce que je peux te conseiller, c'est de penser à intégrer iBATIS à ton application pour gérer de manière simple et optimisée ces différentes requêtes multi-critères. ça vaut le coût et en plus Hibernate et iBATIS peuvent parfaitement co-exister.

ça c'est une idée qu'elle est bonne. Je commençais effectivement à envisager de trouver une solution alternative à Hibernate pour cette partie, d'autant que nous en avions déjà parlé dans l'équipe et que nous savions que nous allions devoir implémenter d'autres solutions pour certaines contraintes.

Je vais tâcher de jeter un coup d'oeil de ce côté. Merci du conseil.