Discussion :

[zach]

Apres plusieurs tentatives avortées, je me tourne vers vous.
J'ai une grosse table(environ 200 000 lignes) dont je dois afficher les lignes et sur laquelle je dois effectuer un filtre.
J'ai essayé 2 solutions ms dans les 2 cas, il est impossible d'afficher toute la collection de données(timeout), j'en affiche donc que 10 000. Par contre, pour mon filtre il me faut toutes les données.
1)avec les EJB, pour l'affichage ça ne pose pas de probleme par contre, comme pour le filtre ça pose pb. Je récupere une collection de données de la façon suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
public Collection getDonnees() throws TechniqueUtilException{
		try {
 
			//appel de la requete ejb ql declaree dans le descripteur
			Collection colDonnees = tr_partenrLocalHome.findAll();
			Collection colPartenrDTO = new ArrayList();
 
			for(Iterator itColDonnees = colDonnees.iterator();itColDonnees.hasNext();){
				//creation du nouveau dto
				PartenrDTO partenrdto = new PartenrDTO();
				//recuperation de chaque dto de la collection
				Tr_partenrLocal tr_partenrLocal = (Tr_partenrLocal) itColDonnees.next();
				//recuperation de la cle
				Tr_partenrKey key =(Tr_partenrKey) tr_partenrLocal.getPrimaryKey();
 
				//set de la cle dans le nouveau dto
				partenrdto.setIdPartenr(key.partenr_id);
				//set du libellé dans le nouveau dto
				partenrdto.setPartn6Id(tr_partenrLocal.getPartn6_id());
 
				//recuperation des cles etrangeres
				Tr_partn1Key key2 = (Tr_partn1Key) tr_partenrLocal.getFk_tr_partn1().getPrimaryKey();
				Tr_partn2Key key3 = (Tr_partn2Key) tr_partenrLocal.getFk_tr_partn2().getPrimaryKey();
				Tr_partn3Key key4 = (Tr_partn3Key) tr_partenrLocal.getFk_tr_partn3().getPrimaryKey();
				Tr_partn4Key key5 = (Tr_partn4Key) tr_partenrLocal.getFk_tr_partn4().getPrimaryKey();
				Tr_partn5Key key6 = (Tr_partn5Key) tr_partenrLocal.getFk_tr_partn5().getPrimaryKey();
 
				//set des partn id dans le nouveau dto
				partenrdto.setPartn1Id(key2.partn1_id);
				partenrdto.setPartn2Id(key3.partn2_id);
				partenrdto.setPartn3Id(key4.partn3_id);
				partenrdto.setPartn4Id(key5.partn4_id);
				partenrdto.setPartn5Id(key6.partn5_id);
 
				//recuperation des partnLocal via la cle
				Tr_partn1Local tr_partn1Local = tr_partn1LocalHome.findByPrimaryKey(key2);
				Tr_partn2Local tr_partn2Local = tr_partn2LocalHome.findByPrimaryKey(key3);
				Tr_partn3Local tr_partn3Local = tr_partn3LocalHome.findByPrimaryKey(key4);
				Tr_partn4Local tr_partn4Local = tr_partn4LocalHome.findByPrimaryKey(key5);
				Tr_partn5Local tr_partn5Local = tr_partn5LocalHome.findByPrimaryKey(key6);
 
				//set des libelles partn
				partenrdto.setPartn1Lib(tr_partn1Local.getPartn1_lib());
				partenrdto.setPartn2Lib(tr_partn2Local.getPartn2_lib());
				partenrdto.setPartn3Lib(tr_partn3Local.getPartn3_lib());
				partenrdto.setPartn4Lib(tr_partn4Local.getPartn4_lib());
				partenrdto.setPartn5Lib(tr_partn5Local.getPartn5_lib());
 
				//ajout du dto à notre collection de retour
				colPartenrDTO.add(partenrdto);	
				}
				return colPartenrDTO;
			} catch (Exception e) {
				throw new TechniqueUtilException(e.getMessage());
			}
 
		}

C'est cette fontion qui a du mal à s'executer!!!!
Pour l'affichage, je fais:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
	public Collection getDonneesTronquees() throws TechniqueUtilException{
		try {
 
			//appel de la requete ejb ql declaree dans le descripteur
			Collection colDonnees = tr_partenrLocalHome.findAll();
			Collection colPartenrDTO = new ArrayList();
 
			int i =0;
			for(Iterator itColDonnees = colDonnees.iterator();i<10000;i++){
				//creation du nouveau dto
				PartenrDTO partenrdto = new PartenrDTO();
				//recuperation de chaque dto de la collection
				Tr_partenrLocal tr_partenrLocal = (Tr_partenrLocal) itColDonnees.next();
				//recuperation de la cle
				Tr_partenrKey key =(Tr_partenrKey) tr_partenrLocal.getPrimaryKey();
 
				//set de la cle dans le nouveau dto
				partenrdto.setIdPartenr(key.partenr_id);
				//set du libellé dans le nouveau dto
				partenrdto.setPartn6Id(tr_partenrLocal.getPartn6_id());
 
				//recuperation des cles etrangeres
				Tr_partn1Key key2 = (Tr_partn1Key) tr_partenrLocal.getFk_tr_partn1().getPrimaryKey();
				Tr_partn2Key key3 = (Tr_partn2Key) tr_partenrLocal.getFk_tr_partn2().getPrimaryKey();
				Tr_partn3Key key4 = (Tr_partn3Key) tr_partenrLocal.getFk_tr_partn3().getPrimaryKey();
				Tr_partn4Key key5 = (Tr_partn4Key) tr_partenrLocal.getFk_tr_partn4().getPrimaryKey();
				Tr_partn5Key key6 = (Tr_partn5Key) tr_partenrLocal.getFk_tr_partn5().getPrimaryKey();
 
				//set des partn id dans le nouveau dto
				partenrdto.setPartn1Id(key2.partn1_id);
				partenrdto.setPartn2Id(key3.partn2_id);
				partenrdto.setPartn3Id(key4.partn3_id);
				partenrdto.setPartn4Id(key5.partn4_id);
				partenrdto.setPartn5Id(key6.partn5_id);
 
				//recuperation des partnLocal via la cle
				Tr_partn1Local tr_partn1Local = tr_partn1LocalHome.findByPrimaryKey(key2);
				Tr_partn2Local tr_partn2Local = tr_partn2LocalHome.findByPrimaryKey(key3);
				Tr_partn3Local tr_partn3Local = tr_partn3LocalHome.findByPrimaryKey(key4);
				Tr_partn4Local tr_partn4Local = tr_partn4LocalHome.findByPrimaryKey(key5);
				Tr_partn5Local tr_partn5Local = tr_partn5LocalHome.findByPrimaryKey(key6);
 
				//set des libelles partn
				partenrdto.setPartn1Lib(tr_partn1Local.getPartn1_lib());
				partenrdto.setPartn2Lib(tr_partn2Local.getPartn2_lib());
				partenrdto.setPartn3Lib(tr_partn3Local.getPartn3_lib());
				partenrdto.setPartn4Lib(tr_partn4Local.getPartn4_lib());
				partenrdto.setPartn5Lib(tr_partn5Local.getPartn5_lib());
 
				//ajout du dto à notre collection de retour
				colPartenrDTO.add(partenrdto);
			}
				return colPartenrDTO;
			} catch (Exception e) {
				throw new TechniqueUtilException(e.getMessage());
			}
 
		}

et là, pas de probleme!

2)en faisant directement les requetes dans les actions. Le pb ici, c'est qu'à un moment, j'ai l'exception "java.lang.OutOfMemoryException". En d'autres termes, la MV n'a pas assez de mémoire.

Je suis donc dans une impasse.
Quelqu'un aurait une idée pour amiélorer les perf de mon appli?

Merci d'avance.

PS:Ne me laissez pas seule avec mon pb, svp!!!






[Modéré par Didier]
Ajout de tag dans le titre
Lire les règles du forum : Règles du forum Java

[ego]

Bon première question, quelle application peut nécessiter l'affichage de 200 000 lignes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!????????????????????

En 14 ans de carrière je n'en ai JAMAIS vu.

Je pense qu'il doit y avoir un sérieux problème d'exigence dans ton application.
Si malgré tout il faut afficher tout cela, je te conseille de procéder par paquets et de dire par exemple :
- Recherche des 100 premiers éléments
- Affichage des 100 éléments
- Demande des 100 suivants
- Recherche des 100 suivants
- Affichage des 100 éléments
etc...

Il ne faut pas faire un findAll mais faire un "findByRange"

D'autre part, tu peux peut être te contenter de ne charger que qq attributs de tes objets et non la totalité et offrir un moyen dans l'IHM pour aller chercher le détail si besoin (sur requête qui ne chargera ici qu'un objet complet).
Pour faire tout cela, je ne pense pas que les EJB entity soient la bonne solution d'ailleurs

[zach]

Ce n'est pas la pire des tables!!! La plus grande a un peu plus d'un million de lignes!!!!!! Je crois que je vais vraiment galerer pour celle là.
Dans l'équipe de développement, on se pose vraiment la question de savoir à quoi ça sert!!! L'application est un Datamart.
Je vais essayer la méthode que tu m'as proposé. Par contre, le client est assez rigide et a refusé toutes les solutions qu'on lui a proposé donc je suis obligée de récup ts les attributs.
En fait, l'ihm de l'appli etait gérée sous access. Mais ils ont voulu passer sous Websphere et avoir exactement les mêmes IHMs!!!!!!!
Merci d'avoir répondu aussi vite

[ego]

il y a VRAIMENT UN PROBLEME de conception de l'application
Que va faire ton client avec une page contenant 200 000 ou 1 million de lignes !!!!!!!!!!!????????
Que va-t-il trouver là dedans ????????????????

Ne vous laissez pas faire car vous aller tomber dans un piège classique = faire qq chose d'impossible et totalement inutile. Ton client va se réveiller un jour et là il te reprochera de ne pas l'avoir mis en garde.

Je suis plus que sincère dans ce que je te dis. Ne cherchez surtout pas à répondre à ce besoin mais dépensez votre énergie à le convaincre. C'est le conseil d'un vieux avec 14 ans d'expérience !

[austin P.]

là c'est clair que votre projet il sent le sapin (et à des kilomètres)

ce que vous demande ce client est tout simplement techniquement irréalisable et profondement stupide.

je parie même qu'il t'as demandé de pouvoir trier les colonnes

Le pire (et là je parie mon maigre salaire) c'est que au final et à l'usage, le client va se rendre compte que l'interface avec 200000 items est d'une telle débilité, qu'à la limite il rique même de t'accuser de l'avoir mal conseillé (et c'est du vécu!!!)

nb : access n'affiche pas tous les enregistrements : il fait du page par page (meme si il y a un ascenceur).

to ego : t'inquiètes c'est bientot la retraite :-D

[ego]

espèce de jeune !!

[zach]

Je vais leur expliquer lundi l'impossibilité d'aqfficher autant de lignes.
Je vais donc en afficher qu'un millier. Par contre pour faire le filtre il faut absolument que je recupere toutes les données!!! Et cette operation est carrement trop lourde!!!! Donc je vais suivre le conseil d'ego. Du moins je vais essayer
Par contre, il est plus aisé de pâsser par jdbc donc est ce que voous auriez une soluce pour augmenter la memoire de la machine virtuelle?
En tout cas, merci pour vos precieux conseils car je suis un peu novice sur le projet(moins de 3 mois) et j'ai du apprendre à maitriser Websphere en un mois donc il me manque encore des connaissances.

[austin P.]

concernant les fitres, il est possible que tu doive utiliser directement du sql pour les exprimer

je voudrais pas avoir l'air de tout peter mais ne pense tu pas qu'un hibernate ou JDO te serai plus utile plutot que des entity ?

l'avantage c'est qu'il te permet d'exprimer programaticalement (super français) du sql objet. Tu pourras donc exprimer tes filtres en sql objet et donc le load des items n'en sera que plus fin. En plus en activant le lazy loading, il est possible d'être encore plus parcimonieux avec la mémoire.

sinon il existe un pattern : values list handler qui propose de régler cette problématique
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html


concernant le réglage de la mem, il ne faut pas rever : tu peux jouer sur les parametres xms et xmx mais tu pourras difficilement dépasser 1Go.

Enfin tu as grand intérêt à verifier les contraintes du client en terme de montée en charge, parceque même si tu reussi à le faire fonctionner à peu près correctement avec un utilisateur, je te promet du bonheur avec 10 et plus.

[zach]

Ca a l'air interessant sauf que je ne connais ni hibernate ni jdo mais je vais me pencher sur la question. Autre chose : ça fonctionne bien sous websphere? Si oui, comment?
Merci austin pour t'aide, elle est precieuse.
(merci aussi à toi ego 8) )

[zach]

Je viens de discuter avec un collègue qui m'a parlé des procédures stockées.
Que pensez vous de cette solution?

[ego]

cela ne change rien à ton problème !!!!!!!!!!!!!!

[oca]

Hello,

Je rejoins completement ego et austin.
chez nous, on a aussi des tables de plusieurs millions d'enregistrements.

par defaut, on n'affiche que les 100 premiers et c'est bien suffisant.
Il est par contre interessant de pouvoir paginer pour obtenir les 100 enr. suivants etc...

Sinon, Je connais pas trop les EJB mais pour ce qui est du filtage, et des perfs, cela va forcement remonter jusqu'à la DB.
Donc il faut que tu vérifes que tu aie bien TOUT les indexes nécéssaires.

Une autre piste : A mon avis, une seule requète avec des jointures est plus efficace qu'une multitude de petites requètes...

A+

Oliver

[zach]

Oh! Ego, faut pas me crier dessus comme ça
Je pensais qu'en faisant appel à une procédure stockée, ça pouvait peut être m'éviter de charger toutes les lignes de ma table. Genre, de faire d'abord un filtre et de récuperer seulement le resultat du filtre. Dans le cas où il y aurait toujours trop de données, ben j'en affiche que les 1000 premieres. Par contre, je ne sais pas du tout si je vais encore avoir l'erreur OutOfMemoryException. J'essaie juste de trouver une solution performante.
Merci oca pour l'idée des jointures

[LoulouFifi]

Bon j'ai pris connaissance de toute l'affaire (quelle affaire!...)
et mon avis :
"Mais c'est quoi ce bordel???!!...."
:
Ca déja été dit, mais je le répète : mieux vaut mettre son énergie pour changer la conception que de développer cette solution inutile et inimaginable...
Après, pour la solution du PL/SQL c'est une bonne solution (j'ai eu à migrer des traitements faits en VB en PL/SQL et niveau perf c'est clair, c'est nickel)....Par contre, ça résoudra que partiellement ton pb, car faire des procédures pour afficher 200 000 lignes ça le fera avec des temps de réponses meilleures que d'autres solution, mais est-ce vraiment là, la solution ???!!...

[zach]

Ben vu que c'est peut etre le fait de faire des traitements sur 200000 lignes qui fait planter la machine virtuelle, je me suis dit que si on recupere que 10000 données deja traitées par PL, l'appli serait peut être plus performante.
Mais j'ai l'impression de faire fausse route
Dites moi ce que je dois faire car à chaque fois que j'ai l'impression de mettre le doigt sur la solution, ben... ça n'a pas l'air d'être top
Help!!!!!!!!!!

[LoulouFifi]

Tout le monde te l'a deja dit je crois :
Ce n'est pas sur la solution à mettre en place qui faut te pencher mais sur le pb lui-même : c'est à dire l'affichage d'autant de lignes!!
Tu pourras mettre en place du PL/SQL, des requetes, des traitements batch...etc tout ce que tu voudras, ça résoudra rien du tout car le pb vient de plus haut : le besoin débile du client!!!
Tente de mieux spécifier son besoin, et de trouver une solution fonctionnelle et conceptuelle plus plausible a mettre en place (et surtout utile pour le client) et apres la technique et le développement viendra tout seul...

[austin P.]

effectivement il est préférable de limiter le nombre de ligne et 10000 c'est déjà (à mon avis) beaucoup trop. Essai d'iimaginer une interface type google qui permet d'aller de page en page. Comme ca tu peux limiter le retour du nombre d'objet.

[zach]

C'est exactement à ça que je pensais austin!!!!!!!
Comme je l'ai déjà dit, le client est plutot rigide. J'ai deja reussi à leur faire accepter le fait qu'il n'y aura pas toutes les données affichées.
Pour vous donner une idée, à la derniere reunion pendant laquelle on devait leur presenter l'appli sous websphere, devinez ce qu'ils ont dit???
"Mouais ms maintenant on ne pourra plus bidouiller"!!!!!!!!!!!!
Bref, ça devrait aller pour l'affichage. Pour le filtre, je pensais recuperer directement les données filtrées via PL. Ainsi, je n'aurais plus à effectuer le traitement à partir du code java.
On va voir ce que ça va donner. Surtout au niveau mémoire machine virtuelle.
Merci à tous et n'hesitez pas si vous voyez une meilleure soluce!!!!

[austin P.]

sincerement si tu as beaucoup de filtres à exprimer, utilise hibernate ou jdo pour faire du hql/oql. Si tu fais de la proc stock mélangé avec de l'entity c'est pas trop la classe.

En clair des sessions stateless en facade pour la couche métier et hibernate pour la couche objet métier.

[zach]

Rassure toi austin, je ne melange pas tout. Je ne passe pas par les entity pour les grosses tables mais seulement pour les tables "normales".
Je pense que je me pencherais vraiment sur ta solution mais apres la livraison car j'ai vraiment les mains liées et tres peu de temps. Je fais deja des heures supp pour tout finir à temps.
En tout merci pour tout. Je pense que ça aidera plus d'un