Cerrar ResultSet

[micayael]

Hola amigos.

TEngo un problema existencial con una clase de conexion en java. Esta clase crea la conexion a través de un método estatico llamado conectar entonces tengo Conexion.conectar().

El problema es que tengo otro metodo Conexion.consultar(String sql) que devuelve un ResultSet. Este resultset nunca se cierra ya que si lo cierro no podrìa ser devuelto en el metodo y necesito el ResultSet dentro de la aplicación para formar tablas o hacer otras operaciones.

Como se debería mantener esto? Creo que debría haber una mejor manera de hacer para que se pueda cerrar el ResultSet.

[vljc2004]

cómo lo tiene declarado?.

Supongamos que esta asi: public ResultSet rss;

Solo le das rss.close(); y ya.

[micayael]

Claro. Se como cerrarlo. Lo que pasa es que tengo por ejemplo dos clases.

Conexion y Principal

En conexion está mi método que devuelve el ResultSet que es llamado desde Principal lo que quiere decir que no lo puede cerrar en la clase Conexion. porque si lo cierro me devuelve null.

En Principal tengo asi.

ResultSet rs = Conexion.consultar(sSQL);

Una referencia viene a mi variable rs en Principal y ese si lo puedo cerrar pero no puedo cerrar el que queda abierto en Conexion. Me explico?

[GreenEyed]

Si no he entendido mal, en realidad son el mismo ya que lo que tu devuelves es una referencia al mismo ResultSet, no una copia, asi que no hay dos. Con cerrar el que devuelves basta.

S!

PD: De todas formas, con ese diseño dependes de que el codigo externo que llames cierre el ResultSet, lo cual puede presentar problemas de mantenibilidad.

[micayael]

Tienes razón GreenEyed lo estaba mirando como una copia pero el metodo close() es del objeto que reside en memoria.

Y de que otra manera puedo diseñar esto? para tener un metodo que haga las consultas y no tener que hacerlas siempre desde el Statement y todo lo que implica?

[GreenEyed]

Ummm depende.

Se puede por ejemplo devolver un List de los objetos que devuelve el resultSet. Y para cada objeto usar un Map (campo,valor), por ejemplo.

O dejar que sean los metodos los que ejecuten sus propias consultas y asi abran y cierren sus resultSet.

O dependiendo de lo que suelas hacer con esos metodos, puedes hacer un metodo generico que ejecute la consulta, le pase el ResultSet a algo que tu implementes y que luego cierre el ResultSet. Algo así como el "Action Pattern".

Cada uno tiene sus ventajas e inconvenientes, y es cuestion de elegir. Yo para mis accesos a BDD, suelo usar el último pero me sirve por que se que siempre devuelvo en mis metodos el mismo tipo de valores.

S!

[elAntonie]

Iniciado por GreenEyed

O dependiendo de lo que suelas hacer con esos metodos, puedes hacer un metodo generico que ejecute la consulta, le pase el ResultSet a algo que tu implementes y que luego cierre el ResultSet.

Wenas.

O una clase que se encargue de la BD. ejecute la sentencia y te devuelva un arraylist o un vector o algo similar.

Tu llamaras a esa clase con una sentencia sql y recibiras el arraylist.

Esta clase creara la conexion, ejecutara la consulta y cerrara la conexion.

La idea es que tu clase de negocio le importe un flautin como se obtengan los resultados, y no tenga que preocuparse de resultsets ni historias.


Saludos.

[GreenEyed]

Iniciado por elAntonie

Wenas.

O una clase que se encargue de la BD. ejecute la sentencia y te devuelva un arraylist o un vector o algo similar.

Tu llamaras a esa clase con una sentencia sql y recibiras el arraylist.

Esta clase creara la conexion, ejecutara la consulta y cerrara la conexion.

La idea es que tu clase de negocio le importe un flautin como se obtengan los resultados, y no tenga que preocuparse de resultsets ni historias.


Saludos.

Esa es la primera opción que he puesto . De cualquier forma, la idea es que dado que es un codigo que se va a ejecutar muchas veces y tiene una parte "sensible" como es el tratamiento de las conexiones, puedas "garantizar" que siempre se hace el tratamiento correcto.

S!