Discussion :

[chess]

Bonjour,

Dans le contexte de mon application, je suis améné à lancer une requete SQL qui renvoi + de 100.000 resultats sur plusieurs colonnes. Mon client m'impose de n'avoir aucune limite de résultat car il souhaite parcourir ("browser") l'ensemble de ces resultats.

Pour l'instant, j'utilise un système custom pas trés propre dans le sens où j'execute l'intégralité de la requete via un objet QueryRunner (Apache Common DbUtils) qui me renvoi un objet type ArrayListe que j'envoi en sessionpour paginer ensuite à l'affichage. Le problème de cette solution est la consommation mémoire non contrôlée et les crash mêmoire qui en resulte.

La question est donc :
Existe-il des librairies permettant de gerer ces cas correctement. Par exemple, executer la requete en table temporaire en y ajoutant les datas nécéssaires au parcours des pages (un numero de ligne par exemple) ?
Je suis prenneur de n'importe quel autre conseil ou méthode pour la résolution du problème.

Je n'utilise aucun framework (juste Freemarker comme moteur de template) et mon application utilise MS SQL 2005 et Tomcat 5.5 comme serveur d'app J2EE.

Merci par avance.

[tchize_]

pourquoi tu n'utilise pas simplement les clauses de limitation des requetes sql, que supporte toute base de données. C'est performant et dédiè à ca.

[chat hotplug]

Exact. Ajaxifie ton code avec pagination. Pour récupérer un plage de résultats sous MySQL tu as la clause LIMIT. Sous Oracle c'est plus mais tu peux jouer avec ROWNUM et obtenir la même chose. De plus... je te conseille de mettre des caches sur les appeles ajax (easy si tu kiff' jQuery) sur les appels de methodes Java si tu aimes Acegi Security par exemple et de mettre des index intelligents sur la base de données pour booster le bazarre. Good luck.

[tchize_]

t'es pas obligé de jouer avec limit, les objet Statement et ResultSet en java possèdent les méthodes indépendantes de la bd pour gérer çà:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
statement.setFetchSize(5) // prendre 5 lignes à la fois dans la db
resultSet rs = statement.exectuteQuery(......);
rs.absolute(5000); // se déplacer à la 5000ème ligne
rs.next(); //on avance d'une ligne
rs.next(); //on avance d'une ligne
//etc

Devrait faire ton bonheur.

[chess]

Merci à tous, mais je crois que j'ai mal exposé mon problème. L'outil intègre une une sorte de moteur de recherche. A la base, j'avais défini un paramètre modifiable qui limitait le nombre de résultat de la requête. Etant sur MS SQL Server, j'utilisais ce paramètre avec TOP. Genre SELECT TOP x.

J'avais fixé ce paramètre à 5000, ce qui me paraissait plutôt honorable car si on lit les stats sur le parcours de résultat par les utilisateurs, ce parcours s'arrête souvent à la première page.

Le problème est que mon client est capricieux (ce que le client veut...) et il souhaite avoir tous les résultats même s'il doit se taper le browse sur plus d'une centaine de page de résultat.

Je cherche donc une solution technique qui me permette de naviguer (avant/arriere) par page dans un résultat important, sans que cela torture la mémoire de la JVM.

Voila, dsl.

[tchize_]

et il me semble que c'est ce qu'on t'as répondu. Tu limite le nombre de row renvoyés par ta requete et tu précise quel row est le premier. Ensuite, la navigation consiste simplement à passer de 5000 en 5000 sr la valeur du premier row. Bien sur, la requete est à exécuer à chaque fois, mais comme tu limite le nombre de résultats à 5000 ça va pas torturer ta JVM Même que, en pratique, si tu écrit les résultats dans le stream de sortie au fur et à mesure de la lecture des row, t'aura meme jamais 5000 données en mémoire

[chess]

Ok.

Le soucis, c'est que la recherche est multicritere et qu'elle s'exécute assez fréquemment en 20 secondes. Je voulais éviter de relancer la requête plusieurs fois.

Visiblement, le setFetchSize bénéficie d'une réelle implémentation sur SQL 2005 et pourrait donc éviter de saturer la mémoire, ce qui ferait de ta solution (tchize_) la fin de mes soucis. Pensez-vous qu'il serait stupide de déclarer le resultSet en variable de session pour éviter de re poster la requête ?

[tchize_]

c'est un risque de voir tes Connection disparaitre dans les sessions utilisateur. Ces dernière mettent du temps à être nettoyées quand elles ne sont plus utilisées. Je ne connais pas sql server, mais tu peux aussi peut être regarder si il n'existe pas l'équivalent des View en Oracle, tables virtuelles qui sont créées à partir de requêtes de type Select.

[chess]

Je pense que c'est jouable de faire du nettoyage. Toute mon application fonctionne avec des codes de fonctions. Ca me permet donc de fermer proprement lors de l'appel à toutes fonctions ne faisant pas partie de la navigation dans cette recherche.

Je vais donc mettre en oeuvre cette solution. Merci à tous et en particulier à tchize_ pour son aide.