Newsgroup: it.comp.java
Titolo: Serializzare un ResultSet

Ciao a tutti,
ho il seguente problema:
dovrei passarmi in locale i risultati di una query (circa 2.000.000 di
record). Non importa se in una struttura tipo Vector o in un file.
Mi sono creato una classe d'appoggio per contenere tutti i campi dei record
del ResulSet.
andando avanti con la resultset.next faccio un ciclo all'interno del quale
eseguo una new della mia classe, riempio i campi e scarico il record su
file.
Il mio problema è che al 700.000 elemento circa ho un errore di out of
memory.
Mi sapreste dire che struttura usare o in che modo potrei passarmi queste
informazioni su file in modo da poter effettuare operazioni di ricerca
conteggio ecc sui record?
Grazie 1000 .
Giuseppe

 ricerca conteggio ecc sui record?
Primo consiglio (logico): ricerca e conteggio falli fare al database, che č 
il suo mestiere.
Secondo: se scarichi il contenuto su file riusa la stessa istanza 
dell'oggetto. per due milioni di volte butti un oggetto nel garbage e ne 
crei uno nuovo, č una inutile sollecitazione che da (appunto) questi 
effetti indesiderati.

 effetti indesiderati.
Ho provato ad usare sempre la stessa istanza, ma in questo modo il risultato
che ottengo č quello di avere tutti i record con gli stessi valori.
Giuseppe



Ciao,
per aumentare la memoria massima che può utilizzare java, devi aggiungere:
java -Xmx512m <il tuo prg>
in questo casi java potra utilizzare fino a 512M di memoria (quindi
dovrebbe andare).
Ciao, Davide
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com
 - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

 ha scritto nel messaggio
news:pan.2004.02.15....@miomail.ch...


 valori. 
Dal messaggio originale sembrava tu stessi trasferendo i dati su file, 
invece adesso mi sembra di capire tu ti voglia caricare il resultset in 
memoria. In questo caso, non è che hai tutti i record in memoria uguali ma 
hai una collection di n-elementi che puntano allo stesso oggetto. Non è 
quello che vuoi. Per avere tutto il resultset in memoria devi avere un 
istanza dell'oggetto per ogni record, quindi 2 milioni di istanze, la cui 
dimensione in memoria sarà almeno quella del record. Senza contare che ti 
terrai in memoria anche il report nonchè i risultati dell'elaborazione 
intermedi. Non è difficile prevedere che ti serve qualche giga di memoria 
fisica...

 tipologie di ricerche e conteggi sulla struttura in locale.
In genere, se il database e' buono e sufficientemente "tuned"
l'impatto di piu' query successive simili (cioe' che fanno le stesse
join e usano li stessi indici) puo' non essere terrible - specie se
l'ottimizzatore e' statistico.
Comunque. 
Il modo migliore di trattare 'ste cose e' di modellare i dati in modo
da potercisi riferire a "blocchi" (cioe' poter caricare le prime 10,
100, 1000 righe eccetera): di solito si fa con parti apposite della
PK, oppure, in Oracle ad esempio, con colonne fittizie tipo ROWNUM.
Eventualmente, denormalizzare le tabelle e/o mantenere risultati
parziali (penalizzando l'inserimento per velocizzare la selezione) e'
certamente una delle cose piu' comuni.
Altrimenti, il punto e': prendi il limite superiore del risultato, e
prendi la quantita' di memoria disponibile alla JVM. Il primo sta
nella seconda? Se no, non c'e' verso: i database sono il modo piu'
efficiente di lavorare *non* in memoria. A meno di casi particolari,
non val la pena cercare di far meglio reinventadosi sistemi di
gestione dati su disco (occhio che in casi particolari, puo' valer la
pena, ma dipende dalla natura dei dati _e_ del loro uso) e
semplicemente _non_ salvare il risultato ma usare query successive,
definendo indici e view in modo opportuno.
Se si', o quasi si', puo' valer la pena cercare di ottimizzare
l'allocazione in memoria: per esempio, trattando i dati in modo
compatto, come array di caratteri o stringhe ad esempio, piuttosto che
creare singoli oggetti.
Se l'accesso e' localizzato (cioe' un certo blocco di dati viene
acceduto, processato e poi non e' piu' toccato) puo' valer la pena
costruire un layer che "presenta" l'informazione come completamente in
memoria ma in realta' esegue caching e paginazione on-demand. In
termini prestazionali questo spesso tende ad essere equivalente ad
eseguire query successive, con la differenza che hai esattamente il
controllo di cosa rimane cached - e perche'.