Discussion :

[l.bruninx]

Comme je lai bien indiqué dans ma réponse précédente, j'ai simplement proposé une généralisation du procédé de mémoisation. C'est pour cela que j'ai utilisé une Hashtable disponible dans Java SE sans nécessiter de paquetage supplémentaire.

Pour ce qui semble être un problème avec JTable, il serait peut-être utile de donner plus de détails sur ce qui se passe. S'agit-il d'un problème d'actualisation de l'affichage de la table?

[NeptuS]

Désolé, mais tes explications sont un peu floues :

je pense que l'utilisation du cache de mon SGBD aurait été suffisant si et seulement si je vais extraire les memes valeurs de la base de données. mais ce n'est pas le cas pour moi,

- Premièrement, je dirai qu'utiliser des procédures stockées te permet de bénéficier des optimisations du SGBD. Donc c'est bien.
- Deuxièmement, la mise en cache du SGBD ne concerne pas 1 requête, mais autant que possible.
- Troisièmement, si tu n'extrait pas les mêmes valeurs, aucun cache ne pourra t'aider. tu dois juste avoir l'implication (params) => resultat et ton cache (peu importe le système, mais celui du SGBD est "correct") sera suffisant.
J'admet que la perte de temps en allocation et traitement dû à l'appel de la procédure stockée côté java te retarde un peu.
- Et enfin : Lorsque tu gère un cache, tu perd partiellement la synchronisation avec tes données. En effet : si une donnée change entre le moment où tu la mettra pour la première fois en cache et la dernière fois que tu l'appelle, c'est cuit. Pense à flusher ton cache aussitôt que cela devient utile.

[Robin56]

Désolé, mais tes explications sont un peu floues :

- Premièrement, je dirai qu'utiliser des procédures stockées te permet de bénéficier des optimisations du SGBD. Donc c'est bien.
[...]

Ou alors, s'il voulait plus simple, il y avait HashMap ou LRUMap. C'est pas forcément très optimisé mais ça remplit son rôle pour un petit besoin de ce genre. Mais j'ai toujours pas compris ce qui bloquait pour son utilisation.

Si quelqu'un peut m'éclairer ?

[l.bruninx]

En fait, Rouge87 devrait être plus clair dans ses explications.

Il commence en parlant d'un problème d'optimisation (mise en cache) qu'il veut manager lui-même.

Puis, un peu plus loin, il laisse entendre qu'il rencontre un problème avec JTable.

N'y aurait-il pas moyen d'avoir un bilan plus précis et comprenant des détails directement liés aux soucis à résoudre.

Pour t'aider Rouge87, il nous faut plus d'informations. Tu nous donnes quelques tranches de codes (je pense que c'est toi qui les fournis), mais on ne sait pas exactement à quoi ils correspondent. Quels sont tes objectifs concrètement ?

Sans plus d'informations et de précisions, nous allons, dans notre bonne volonté, nous disperser dans divers explications qui seront aussi inutiles que hors sujet.

Peux-tu mieux baliser ta question, svp?

[ROUGE87]

Garder un cache de composants graphique n'est pas vraiment une bonne idée

Pourquoi ce n'est pas une bonne idée ?!

[tchize_]

parce que les composant swing ne sont pas prévue pour avoir plusieurs parent, et que si tu fais

panel.add(mafonctionquifaitducache(monparametre))
et plus tard
panel.add(mafonctionquifaitducache(monparametre))

tu risque de retrouver avec le meme composant dans deux panneaux différents.

[ROUGE87]

parce que les composant swing ne sont pas prévue pour avoir plusieurs parent, et que si tu fais

panel.add(mafonctionquifaitducache(monparametre))
et plus tard
panel.add(mafonctionquifaitducache(monparametre))

tu risque de retrouver avec le meme composant dans deux panneaux différents.

j'ai pu éviter ce problème en ayant des paramètres différents pour les différentes méthodes auxquelles je fais appel. je fais un seul add par méthode et donc, j'évite ce problème.
Sinon, pour le Jtabel, est ce qu'il n'a pas un moyen de conservation dans la mémoire (avec le méthode de remplissage que j'utilise) ?!

[l.bruninx]

Le problème, c'est qu'on ne sait pas comment tu remplis ta JTable.

J'ai vu un appel vers la méthode addrowtotable(jTable1, v);

Mais, par expérience, je crois l'avoir déjà dit, il ne faut pas essayer d'accéder directement aux données internes d'une JTable.

Elles pourraient par exemple être modifiée, mais sans que l'affichage de la JTable soit affecté. Il y aurait alors une différence entre ce que l'on voit à l'écran et le contenu interne.

Ainsi, il est effectivement possible d'utiliser l'espace de stockage d'une JTable (en gros, c'est une sorte de tableau). Mais pour accéder aux données, il est de loin préférable d'utiliser les méthodes:
public Object getValueAt(int row, int column);
et
public void setValueAt(Object aValue, int row, int column);
de la classe JTable.

En examinant ton code, une question me vient à l'esprit: Le nombre de colonnes de ta table varie t-il à chaque ligne? Je ne suis pas sûr que JTable fonctionne comme cela. Je pense à ta méthode insertColumn(...);