java - example - JDBC Resultset vs Rowset, ¿cuál elegir y cuándo?

spring jdbctemplate configuration

Question

Así que estoy al tanto de algunas diferencias relativas, es decir, el ResultSet tiene una ''conexión abierta'' a la base de datos, mientras que un RowSet funciona de forma ''desconectada''.

Pero eso es más o menos lo que entiendo (puede ser incorrecto :)

Mi pregunta es esta: ¿en qué circunstancias es preferible una sobre la otra? ¿Cuáles son cada una de sus fortalezas / debilidades?

• Por lo que creo que es un RowSet, trabajar en modo desconectado especialmente para consultas de "solo lectura", tendría un mejor rendimiento en un sistema altamente concurrente. ¿Es eso correcto? Si ese es el caso, ¿es seguro decir que RowSet siempre es preferible a ResultSet para consultas de solo lectura?

• Si soy correcto, la iteración sobre el RowSet no arroja excepciones de SQL, ¿pero es un beneficio? El otro es que RowSet es serializable. Pero mi preocupación es principalmente desde una perspectiva de desempeño, ¿cuál sería la elección?

• Pero, ¿importa incluso para las consultas de lectura-escritura? ¿Puede sincronizar el ResultSet de nuevo a la base de datos? (No estoy seguro de si eso es posible (puede ser y no puedo recordarlo o buscarlo en Google lo suficientemente bien) Ha pasado un tiempo con JDBC en bruto ...

¿Algunas ideas? Hay algunos vacíos que faltan en mi conocimiento, como es evidente :)

El motivo por el que lo pregunto es que me gustaría elegir entre implementar la Interfaz ResultSetExtractor de Spring-Jdbc en lugar de devolver un SqlRowSet al procesar algunos datos. Esta pregunta me dio curiosidad sobre cómo decidir qué elegir cuando, aparte de lanzar una moneda :)

Answer 1

RowSet

RowSet es casi siempre la elección correcta, tiene más funciones y todos los beneficios que enumeró, además de tener implementaciones especializadas para fines especiales, como el CachedRowSet desconectado, que es lo que siempre uso cuando los datos caben en la memoria, por lo que Puede liberar la conexión a la agrupación lo más rápido posible para volver a utilizarla.

ResultSet nunca debe ser parte de un contrato público.

Un ResultSet/Rowset conectado nunca debe escapar del método o, en el peor de los casos, del objeto que los creó. Al menos con un RowSet puede desconectarlo y el cliente no tiene que preocuparse por la implementación. * A menos que esté escribiendo un código de biblioteca específico de JDBC que interactúe o se base en características o contratos específicos de ResultSet .

Si solo está transfiriendo los resultados de una consulta, las clases específicas de JDBC deben ser parte de su contrato público.

Lo ideal es que desee materializar el contenido de RowSet/ResultSet en objetos de dominio seguros de tipos para transmitir.

En la mayoría de los casos, desea materializar una List/Set de objetos de dominio para manipular y trabajar, en lugar de acoplar su código directamente a la API de JDBC .

Muchas tomas modernas en una clase ResultSetMapper<T> existen para manejar la generación de instancias de dominio de tipo seguro usando un patrón de Visitor porque esta es la forma idiomática de hacer las cosas.

Answer 2

No estoy de acuerdo con la respuesta de JR. El RowSet suele ser una buena opción, pero como siempre, la mejor respuesta depende de su situación y sus necesidades. El uso de un RowSet para todo no producirá un código disfuncional, pero puede ofrecer un rendimiento más lento que un ResultSet (la implementación común de JdbcRowSet es una envoltura para un ResultSet).

Si necesita usar su objeto de resultado en un código modular que requiere un JavaBean, entonces RowSets cumple con los requisitos mínimos para Java Beans.

Si está desarrollando un código para una aplicación multiproceso / servidor, debe aceptar la concesión de que todos los Java Beans son mutables y, por lo tanto, no son seguros para subprocesos. Como resultado, ni Resultset ni RowSets son seguros para subprocesos.

Si está escribiendo código que consume consultas de base de datos y las traduce en objetos de modelo de datos Java para usar en el resto de su aplicación, es probable que RowSets tenga menos rendimiento que los conjuntos de resultados.

En una gran cantidad de código que he estado escribiendo, cuando recibí una consulta de base de datos JDBC, simplemente he estado usando el conjunto de resultados para procesar las filas de recuperación inmediatamente en una lista de objetos de modelo de datos. El conjunto de resultados ni siquiera sobrevive a la llamada de método que realiza la traducción. En mi opinión, esto es bueno ... porque los conjuntos de resultados (y, por lo tanto, los conjuntos de filas) consumen muchos recursos y desea que estén disponibles para gc tan pronto como sea posible.

En este modo, ni siquiera necesito ninguna de las características más nuevas de Resultset, y mucho menos RowSet. Simplemente itero hacia adelante una vez a través del conjunto y genero una Lista de filas de resultados.

Hay situaciones en las que los RowSets son altamente deseables. Dado que los RowSets son serializables y ostensiblemente "ligeros", el CachedRowSet desconectado (por ejemplo) representa un mecanismo razonablemente eficiente para transmitir resultados de consultas de bases de datos entre ubicaciones, especialmente si desea que los datos se actualicen in situ. Por supuesto, también podría serializar y transmitir una Lista de objetos.