RE: Manipulation de gros tableaux: 2

[Erik Mazoyer]

J'ai déjà mis en place des architecture équivalente.
La meilleur solution est le multicouche :

1) JTable
2) Un TableModel qui est capable de déterminer l'identifiant d'un élément en
x,y
3) Un manager d'élément capable de renvoyer un élément à partir de son
identifiant

Pour le manager j'utilise SoftReference (pas WeakReference, qui a une durée
de vie vraiment trop courte) couplé à une Hastable.

Algo
Existe t'il une entrée dans la Hastable correspondant à l'identifiant
Oui
        Récupérer la SoftReference
        L'élément référencé est-il toujours en mémoire
        Oui
                Le retourner
        Non
                Le recréer à partir de la SGBD
                Placer l'élément dans la Hastable
                retourner l'élément
Non
        Créer l'élément à partir de la SGBD
        Placer l'élément dans la Hastable
        retourner l'élément

Tu aura donc une empreinte mémoire de 128000 identifiants au minimum. En
utilisant 8 octets par identifiant tu obtiens 1000 ko par tableau.

Après, le temps de réponse de ta JTable dépend de ta mémoire et du nombre de
tableaux affichés simultanément (plus de SoftReference conservé).

Attention, Swing est assez pervers pour interroger les TableModel même quand
le JTable n'est pas affiché.
Il peut être judicieux de mettre un model vide quand le JTable n'est plus
visible (principalement avec les JTabbedPane.

Cordialement,   

--------------------------------------------------------------------
Erik Mazoyer, Chef de projet
HyperOffice
6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
Tél. 01 41 96 96 76
Fax 01 41 96 96 77
Mél  [EMAIL PROTECTED] 
 

-----Message d'origine-----
De : Aurelien Mazurie [mailto:[EMAIL PROTECTED]]
Envoyé : jeudi 28 novembre 2002 22:52
À : [EMAIL PROTECTED]
Objet : Manipulation de gros tableaux: 2



        J'oubliai =)
        J'ai regardé pas mal de documentation là dessus, et je suis tombé
sur 
une histoire de SoftReference, qui apparemment pourrais me servir: si 
j'ai bien compris l'idée c'est de charger mes données dans un gros 
Object[][], et d'en garder une référence via une SoftReference, qui me 
garde les données en mémoire (pas de garbage collect) tant que 
l'application n'a pas besoin de cette mémoire. Si c'est le cas, l'objet 
est viré, et sera éventuellement rechargé plus tard si l'utilisateur en 
a besoin. Cela semble être la panacée ?
        De façon générale, pouvez-vous me confirmer que c'est du côté du 
garbage collector et des systèmes de références qu'il faut que je 
regarde pour gérer de grosses quantités de données ?

        Aurélien Mazurie