Newsgroup: it.comp.java
Titolo: Problema con grosse moli di dati

Ho una JTable che dovrebbe contenere i risultati di una query. Il 
problema e' che quando il numero di dati e' molto elevato l'oggetto 
Vector utilizzato dal DefaultTableModel della Jtable che contiene i dati 
va logicamente in OutOfMemoryError quando eseguo troppi inserimenti.
Eppure devo fare in modo che l'utente possa scorrere nella tablla TUTTI 
i dati della query .
Potrei forse fare in modo che carichi al massimo N righe dal resultset 
al Vector , per poi far rieseguire la query e rifar scrorrere il 
resultset nel momento in cui volessi accedere ai dati successivi ai 
precedenti N, ma poi il DefaultTableModel verrebbe svuotato ogni volta!
Avete suggerimenti da darmi?
Grazie
Romolo
-----------------------------------------------------------------------
L'email e' fasulla, fare reply di questo post sul newsgroup di origine
-----------------------------------------------------------------------

 i dati della query .
Non potresti memorizzare le informazioni che ottieni in un altro oggetto
(ad esempio una LinkedList) e poi definirti un tuo TableModel per la
tabella che per gestire le informazioni utilizza l'oggetto che hai deciso
di usare per memorizzare i dati del ResultSet ??
________________________________________________
Se c'è soluzione perché ti preoccupi ??
Se non c'é soluzione perché ti preoccupi ???
________________________________________________

 wrote in message
news:1vpu4ayym7mam$.xaq8nbaxnt3g$.dlg@40tude.net...


Forse non riesco a capire cosa intendi.. posso tranquillamente usare 
qualunque oggetto per memorizzare i dati che vegnono dal resultset, ma 
il problema rimane. Anche usando un ArrayList o una LinkedList nella 
fase in cui mi scorro il resultSet e inserisco ogni riga di dati 
all'interno del  contenitore ( qualunque esso sia) ad un certo punto 
ottengo l' OutOfMemoryError. Considera che ho a che fare con MILIONI di 
record.
Se non ho capito il tuo suggerimento ti sarei grato se fossi piu' chiaro 
in proprosito.
Grazie
Ciao
-----------------------------------------------------------------------
L'email e' fasulla, fare reply di questo post sul newsgroup di origine
-----------------------------------------------------------------------


di usare per memorizzare i dati del ResultSet ??
Definire un TableModel alternativo è la soluzione corretta.
Usando però un LinkedList come backing store per il resulset vuol dire
continuare a conservare tutto il resultset in memoria, quindi anche il
LinkedList ad un certo punto darebbe problemi di memoria esaurita.
Secondo me si potrebbe creare una specializzazione di Vector o di
ArrayList che utilizzi come backing store un file temporaneo... l'idea
è stuzzicante, quasi quasi inizio a lavorarci sopra :P
Se l'interfaccia rimane la stessa di Vector, si possono nascondere
tutte le operazioni sul file. Se poi lo spazio su disco è esaurito (te
ne accorgi dalle eccezioni lanciate quando si tenta di creare nuovi
file o di scrivere in coda ad un file esistente) è sufficiente
lanciare un OutOfMemoryError (anche se è un errore grave, è sembre
possibile lanciarlo con throw, perchè OutOfMemoryError deriva da
Throwable).
L'unico problema potrebbe essere quello delle prestazioni... un Vector
fatto in questo modo è molto lento, quindi dovremmo pensare anche ad
una "cache" interna abbastanza intelligente. Tale cache dovrebbe
cercare di capire almeno quando si tenta di scorrere la lista in modo
sequenziale. In questo caso la velocità potrebbe migliorare
"precaricando" un tot di record dal backing store.
Stai a vedere che salta fuori un gestore di memoria virtuale in java!
(no vabbè ora sto vaneggiando)
--
"tanto va la gatta al largo che affoga"
(per rispondere personalmente leva IlDitoDalCulo)

lanciare un OutOfMemoryError (anche se è un errore grave, è sembre
sembre=sempre
scusate c'ho le dita un po' influenzate
(e dire che "B" e "P" sulla tastiera sono abbastanza lontane!)


Forse è un problema di memoria, non ne hai abbastanza per poter memorizzare 
tutte le informazioni che hai bisogno.
Non so potresti cercare di invertarti qualcosa per effettuare una specie di 
caching dei risultati, magari creando un file temporaneo che memorizza i 
risultati della query. Lo so che non è il massimo dell'efficienza ma 
d'altra parte tutti questi dati dovrai pure sistemarli in qualche 
modo...potresti caricare i primi dati da visualizzare in un TableModel, poi 
quando hai bisogno degli altri te li carichi da file, salvando quelli che 
hai appena visualizzato in un altro file.
Però secondo me la soluzione migliore (se attuabile) è cercare di tirare 
fuori qualche istruzione SQL che limiti il numero di risultati (e questo si 
può fare, te lo assicuro) e magari ti restituisca solamente i record dal 
numero x al numero y, od una cosa del genere (e questo non ti so dire se si 
può fare, ti auguro di sì)
Facci sapere come hai risolto
Un saluto, Claudio


 Romolo

Quanti MB Ram ha il tuo personal computer?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Concordo..



On Fri, 29 Aug 2003 15:39:29 +0200, John Smith <Jo...@JohnSmith.org>
wrote:

Potresti crearti un cursore sulla tua interrogazione (a patto che il
DBMS che usi supporti i cursori) e quindi... estrarti solo un
sottoinsieme di tuple ----> che andranno a popolare la JTable.
In questo modo, ti appoggi al DBMS per estrarre i prossimi k risultati
(il che è sicuramente efficiente).
Ciao, Vito D.

Dunque io farei due osservazioni:
1) La prima proposta di usare liste concatenate mi pare abbastanza assurda
dato che una lista concatenata di sicuro occupa di piu' quanto  un vector
(campo data + campo next).
2) Per quanto riguarda la visulaizzazione:
Non mi sembra una buona soluzione mostrare in un unica griglia milioni di
record, nel senso che non e' gran che fruibile. Non e' meglio rendere la
griglia a piu' pagine (magari ordinate secondo qualche criterio (lettere
iniziali di un cognome, tipologia di dato....)?  Se invece hai l'obbligo di
mostrare tutti i dati in un unica griglia non hai altra soluzione che dei
metodi di buffering: anche i motori di database per mostrare i dati delle
tabelle hanno questa tecnica, basti pensare al tempo di refresh durante lo
scrolling verso il basso. Ora per ottimizzare la richiesta di nuovi dati nel
buffer da visualizzare o si fa una nuova richiesta al DBMS (ma se si alvora
in rete o se il DBMS non e' altamente prestante puo' risultare oneroso) o si
memorizza l'intera richiesta in memoria secondaria (file) e lo scorrimento
della barra nella table corrisponde alla posizione nel file. In pratica la
barra di scorrimento e' come se si muovesse nel file e non nella tabella.
Quando supera l'intervallo del file tenuto in memoria in una struttura dati
tipo vector usata dala tabella si ricarica il vector con nuovi dato di un
nuovo intervallo.
Personalmente penserei ad una riprogettazione a livello di layout piuttosto
che ad una visualizzzione monolitica.


io ho fatto una classe che implementa l'interfaccia list e all'interno 
lavora su un resultset.
poi un tableModel che lavora su list cosicché se i dati sono pochi gli 
passo un arraylist tradizionale altrimenti questa sorta di list su 
Resultset...a dir la verità ancora non ho provato la sua effetiva 
funzionalità :) xò l'idea mi sembra buona l'unico problema e che posso 
ordinare l'ErrayList tradizionale secondo diversi parametri ma penso ke 
se ordino un arraylist di milioni di elementi ci mette una vita quindi 
bisognerebbe implementare qualcosa ke fa ricaricare i dati dal db 
secondo altro ordinamento senza però cambiare il tablemodel che lavora 
su list...ci penserò