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
