On Thu, 09 Jun 2011 20:20:49 +0200, benedetto.porfidia wrote
gli include e le lib sono necessarie? dove vanno messe?
no, a te non servono affatto. servono invece agli
sviluppatori che intendono compilare codice C/C++
o basta solo copiare le dll in c:blabla\system32?
si, a te basta il mero supporto binario di run-time,
cioè le DLLs
perchè le dll incriminate (esattamente il pacchetto del link che hai
indicato) le ho già installate (sempre in c_win_sys32) come anche
le dll di geos e proj. Adesso purtroppo sono a casa e non ho un pc
windows per provare.
mmm ... allora sono dolori di pancia.
in bocca al lupo, e buon debugging 
* nota per il lettore: fare questo tipo di debugging
su WinOz è come andare a cercare un ago in un pagliaio
in piena notte nell'oscurità più totale 
In ogni caso il mio obiettivo è testare un WFS per circa un paio di
GB di dati (circa 500K poligoni) che vorrei fossero sempre
residenti in RAM; ovviamente il servizio non deve erogare tutto il
dataset in una volta, ma vorrei che tutto il dataset sia sempre
"pronto" evitando i passaggi di lettura su disco. E' sensato oppure
è un'idea totalmente fuori di senno? 
no, non è affatto fuori di senno.
BTW sqlite implementa un meccanismo molto elegante che ti
consente di trasferire tutto un intero DB in ram (e poi
eventualmente di salvarlo nuovamente su disco al termine).
ed ovviamente le performances diventano "oltre il
muro del suono"
ma non saprei proprio dirti se il connector JDBC supporti
questa opzione ... a naso direi proprio di no.
in ogni caso puoi ottenere lo stesso risultato
semplicemente dichiarando una cache SQLite molto
generosa:
http://www.sqlite.org/pragma.html#pragma_cache_size
n.b.: una PRAGMA la esegui esattamente come se fosse
una SELECT, quindi basta che la esegui nelle primissime
fasi di avvio della connessione: ma dubito molto che
si possa fare tramite GeoServer.
l'unica differenza è che nel primo caso sicuramente
tutto il db è residente in memoria, nel secondo caso
(cache) le pagine verranno caricate in memoria solo
nel momento in cui sarenno via via interrogate
(insomma, hai un costo di "primo accesso" più alto).
Questa prova la sto facendo su una normale workstation con 4GB di
ram e un dataset limitato di 50k poligoni
qua sbatti contro un muro di cemento armato 
per WinOz abbiamo disponibile solo la versione 32 bit,
che per ovvi motivi non riesce proprio a vedere più di
2 GB RAM (realisticamante, 1.5GB nel mondo reale).
non dovresti avere problemi con il dataset castrato,
ma con quello completo vai sicuramente fuori memoria.
magari potresti provare su Linux 64 bit.
in ogni caso tieni presente che se il DB "sequestra"
una quantità esagerata di RAM, poi probabilmente le
performances globali *calerano*, perchè entreranno
in sofferenza la JVM ed altri componenti critici ...
insomma, andrebbe monitorato accuratamente facendo
un tuning ultra-fine per avere dei benefici reali.
ciao Sandro