Java - consulta de 800000 registros

lo que pasa es que necesito hacer una consulta de aproximadamente 800.000 registros, pero cuando llega a los 281.000 registros se detiene y me manda una exception. aumente la memoria del glassfish y eso no arreglo nada, estoy utilizando una enterprise application y mi webservice esta en el modulo ejb , lo que intente hacer primero fue hacer la consulta de todos los registros, después hice una función que consultara en partes y me fuera guardando los registros en una lista, después intente hacer las consultas en partes desde el cliente lo intente de 100 en 100 de 1000 en 1000 y de 10000 en 10000 y sigue deteniéndose en 281000 registros.

Con los datos que das, cruzo los dedos para que esta información de JDBC te valga (con Postgres sí funciona, yo lo he tenido que usar):

https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#setFetchSize%28int%29

Tendrás que ver la compatibilidad con tu SGBD y asegurarte de usar autocommit a false.

no estoy utilizando jdbc. pero si, utilizando lo que es jdbc asi como dices si se puede, lo que pasa es que estoy utilizando jax ws y ejb, y se maneja por medio de entitymanager y el resultado te lo regresa cono entidades o como un list de entidades

800000 registros en memoria mm no suena bien. ya intentaste aumentar la memoria del glassfish? de los registros que te trae, no hay caracteres raros? tambien podrias loggear el sql generado. me refiero a la consulta en el DBMS, no la del log. La opción de paginar es correcta.

si ya le aumente la memoria asignada al glassfish pero no, se sigue deteniendo en los 281000

ya aumente la capacidad del glassfish, estoy haciendo la consulta por lotes de 1000 y estoy limpiando el garbage collector pero esta ultima volvió lenta la respuesta del webservice. pero sigue deteniéndose mas o menos por donde mismo.

mmm logea la consulta y ejecutala manualmente, despues realiza un count y ve cuantos registros te traería esa consulta, rastrea la excepción, a lo mejor por ahi tiene un try catch que no hace algo.

Oye estaba revisando que mencionbas lo de la exception en el primer post, que menciona esta exception?

en estos momentos la consulta esta en ejecución, orita que me mande la exception la pongo;

Y mmm la excepción?

interrumpi la ejecucion por que ya se habia tardado mucho pero deja la provoco hoy

Ok, o escritorio remoto o team viewer :)

deja checo cada vez me trae menos registros y cada vez dice que mas memoria esta en uso en si todo comenzó con la exception que dice que se excedió el limite de la memoria, pero pues utilizando lo que es jdbc me trae los 800 000 en 3 o 4 minutos sin ningún problema y eso que el resultset lo vacio en una entidad y lo retorno al cliente en una lista de entidades, tal vez sea una configuración del glassfish, voy a investigar un poco mas del glassfish y si encuentro algo que funcione lo publico . estoy pensando seriamente que es el glassfish aun que ya le aumente asta 4096 sin resultado diferente, a si estoy utilizando ejb3 y jaxws;

ok, cualquier cosa por aqui ando, saludos.

si, muchas gracias.

No es nada optimo tener 800000 registros en memoria.
Si tienes una consulta de tipo: , trata de paginarla por ejemplo en mysql .

En tu codigo trata de limpiar todos los recursos utilizados (excepto la conexion por que es costoso abrir y cerrar conexiones en cada consulta) despues de enviar los registros al cliente.

bueno lo estoy haciendo por lotes de 1000 en 1000, y de hecho si vuelvo null todo una vez utilizado, estoy utilizando esto para hacer la consulta EntityManager.createNamedQuery(Tabla.buscatodo, Tabla.class).setFirstResult(ini).setMaxResults(fin).getResultList(); te regresa una lista de nresultados apartir del registro que le indiques. Tabla.buscaTodo es un query que esta en la misma entidad

No se como trabajen internamente las funciones: setFirstResult y setMaxResults, pero a simple vista diria que no filtran los resultados al nivel de la base de datos si no que lo hace al nivel de la aplicacion, prueba a cambiar tus consultas como te comento para verificar que no sea por eso.

bueno son los equivalentes a offset y a limit

Bueno. detrás de glassfish, de tus ejb, de tus entitymanager y de los web services ... ¡ hay un gestor de base de datos !
¿ Cual es ? ¿ has mirado a ver si tiene soporte para ScrollableResultSets (por ejemplo) ?

Porque la solución a tu problema es la misma que en JDBC: conseguir que se usen cursores de servidor, o sea, que sea el SGBD quien mantenga la lista de resulatdos de un select, no tu jvm.

En condiciones normales, tus setFirstResult()/setMaxResults() no sirven para lo que necesitas si el SGBD de fondo no tiene soporte, o no está correctamente configurado, ya que lo primero que va a hacer JPA es almacenar el resultado _total_ aunque luego genere una lista parcial como resultado.

Quizás deberías implementar un query por claves primarias, en lugar de tratar de paginar.

el SGBD esta bien configurado, desde una aplicacion desarrollada anteriormente pero en C jala todos los registros sin problema, si fuera el SGBD entonces no me traeria los registros en esa aplicacion tampoco, o no?.

Es correcto.

Independientemente de que mi teoría sobre tu problema sea correcta (que seguramente no lo sea) lo que dices no tiene sentido.
Yo te estoy diciendo que tu jvm por defecto almacenará todo el resultset si cabe en su memoria (la de la jvm). Dependiendo del código interno, petará con una excepción si se queda sin memoria, o almacenará lo que pueda y punto (tus 281.000 registros).

Para que tu jvm obtenga un número limitado de registros en lugar de todos, tu implementación de JPA debe soportarlo, y el SGBD también (porque es el SGBD quien tiene que almacenar toda la lista e ir entregando por páginas).

En c tenías disponible para tu aplicación toda la memoria que el S.O quisiera darte . En java no. En c seguramente no usabas cursores. En java sí.

si bueno ya quedo solucionado, con esto http://tecno-aspirinas.blogspot.mx/2011/05/problemas-de-memoria.html

muy bien, muchas gracias por la ayuda, ya lo resolví miren esta pagina http://tecno-aspirinas.blogspot.mx/2011/05/problemas-de-memoria.html ,utilice el método clear del entitymanager y despues libere el espacio del gc, lo que hago es consultar de 10000 en 10000, cada 10000 registros que tomo de la bd los envió al cliente para guardarlos en una lista donde estarán todos los registros, antes de tomar los siguientes 10000 registros ejecuto el clear y después libero el gc y listo.

Interesante