Cursores con grandes datos, java heap space

Disculpen, he ingresado al foro debido a que ya he probado lo que se me ha recomendado, pero sin soluciones.

El caso es que un procedimiento en postgres me devuelve muchos resultados en un cursor. Y depues la maquina virtual (aun cuando en los parametros le pongo al CATALINA -Xmx=1024) se queda sin memoria. el aumento mejoro para las consultas de 100 filas, pero hay aun consultas que devuelven cursores de 100000 filas y la JVM me reporta un java heap space error..

este es la manera en que saco los datos de los cursores de postgres:

.....................................................................................
Statement statementData = null;
PreparedStatement statementDataP = null;
ResultSet resultData = null;
ResultSet dataReport = null;
String statement = " procedureone('{va1,var2}') ";

statementQuery.execute("BEGIN");

resultData = statementQuery.executeQuery("SELECT " + statement);

statementDataP = connection.prepareStatement( "FETCH ALL IN \""+ cursorname + "\";" , ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);

dataReport = statementDataP.executeQuery();

dataReport = statementData.executeQuery("FETCH ALL IN \""+ cursorname + "\";");
............................................

cuando se llega a el fetch, la maquina se colgaba con solo 10000 registros, depues de optimizarla, los presentaba, pero ahora vienen 100000 registros y la maquina se cuelga...

sera que todo en java es pedi memoria y comer recursos?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

System.gc()

Ese es tu código realmente? Creo que primero necesitas leer bien la documentación de JDBC... estás corriendo tres queries, no uno. Y de los tres, el segundo nunca lo usas, solamente se queda abierto, lo cual usa mucha memoria en postgres, porque te deja todo listo para que leas datos de ahi pero nunca los lees (sé que nunca los lees porque perdiste ese ResultSet en la linea siguiente cuando creas asignas otro ResultSet a tu misma variable dataReport).

Usar Java no significa que te puedes olvidar por completo del uso de memoria y que se vuelve mágicamente un recurso infinito. El hecho de que no tengas que manejarla de manera tan directa como en otros lenguajes no te libera de estos problemas.
Un query de ese tamaño te va a causar problemas en Java o .NET si no mandas liberar memoria periódicamente. Y eso depende además de lo que estás haciendo con los resultados. Suponiendo que haces una operación con cada renglón y lo desechas por completo, entonces llamar System.gc() cada 500 renglones o algo asi te puede ayudar, para forzar a que se libere memoria de lo que ya leiste y que no vas a volver a usar. Pero si además cada renglón que lees causa que agregues algo a un documento de XML o HTML que tienes solamente en memoria, entonces el problema no es con Java sino con la manera en que estás haciendo las cosas, que podria causarte problemas incluso en C o el lenguaje que fuera porque estás usando mucha memoria. Ciertamente vas a ocupar más memoria en Java dentro de un contenedor J2EE que dentro de un simple programa de linea de comando en C pero en ambos casos la memoria es un recurso finito y con queries de ese tamaño o mayores vas a tener problemas en cualquier lenguaje.
Incluso podria ser que tu problema no sea en Java nada más; si estás corriendo PostgreSQL y tu programa de Java en la misma máquina, toma en cuenta que el query ocupa mucha memoria primero en PostgreSQL y luego en Java. Si este es tu caso, prueba corriendo PostgreSQL en un equipo y tu programa de Java en otro equipo para ver si realmente es sólo Java quien se queda sin memoria.
Si estás generando un documento de XML o cualquier cosa similar con los resultados, entonces no lo hagas en memoria; manda todo a un archivo directamente, o si estás devolviendo HTML pues empieza a devolverlo de inmediato.
Si estás leyendo 100mil registros para calcular un total o un promedio, modifica tu query para que PostgreSQL haga eso, no lo hagas en Java.

Given the choice of dancing pigs and security, users will choose dancing pigs, every single time.
Steve Riley