Lo que hay que mantener vivo y lo que para volver a crear de una manera sencilla base de datos integrada?

Question

En una aplicación de escritorio con una base de datos Derby incorporado, lo que debería mantener vivo (en contraposición a recrear cada vez cuando se habla con la base de datos) para toda la vida útil de la aplicación?

1. Connection y Statement, usando la misma declaración durante toda la vida del programa?
2. Connection, recreando comunicado en repetidas ocasiones?
3. Ninguno de estos. Es decir, la recreación de la conexión y del estado en varias ocasiones?

Desde el punto de vista de un aficionado de la base de datos, parecería razonable para evitar volver a crear cualquier cosa que no necesitan ser recreados, pero es la opción 1 (o 2) en contra de las prácticas estándar o hay algunas desventajas obvias? Se (re) creación de conexiones y caros o no?

Answer 1

En un incrustado aplicación Derby, ambos de conexión y la declaración de los objetos son bastante barato y creo que no debe preocuparse por la creación de ellos cuando los necesite. En los bancos de pruebas unidad de Derby, creamos decenas de miles de conexiones y cientos de miles de declaraciones, sin problemas.

También está bien para mantener su conexión y declaración de objetos con los que el tiempo que desee. Derby Embedded no tiene límite de tiempo, y no dejar caer los objetos de conexión o declaración, a menos que usted le indique a (cerrándolos), oa menos que se escapa a la basura, en cuyo caso el recolector de basura limpiarlos (con el tiempo).

A pesar de que está bien para mantener la conexión alrededor, usted debería comprometerse () la transacción cuando se ha completado (a menos que se ejecuta en el modo de confirmación automática por supuesto).

Y, si está manteniendo un conjunto de resultados alrededor, ser conscientes de que la comisión de la transacción será por lo general también cerrar el conjunto de resultados, a menos que específicamente la construcción de los conjuntos especiales de resultados que se mantienen abiertos en toda cometen.

Answer 2

Conexión de hecho es caro (puede costar unos pocos cientos de milisegundos). La conexión tiene sin embargo una vida útil limitada y el estado de resultados y depende de su tiempo de vida. El promedio de tiempo de espera DB y soltar la conexión cada vez que ha sido puesto en libertad durante más de 30 minutos. Se puede añadir un poco de corrector de tiempo de espera en su código para que se va a volver a adquirir la conexión "automáticamente", pero eso es un trabajo tedioso y muy propenso a los errores, si usted no sabe cómo debe trabajar bajo las capuchas. utilizar más bien una ya existente, bien desarrollado y robusto conjunto de conexiones como C3P0 y escribir el código JDBC de la manera habitual (adquirir y cerrar todos los recursos en el menor grado posible). Esa debería ser la misma.

Aunque en teoría (y aparentemente también en la práctica) en la conexión de bases de datos integradas será menos costoso y una conexión puede sobrevivir para siempre, estoy de acuerdo fuertemente a acercarse a bases de datos integradas de manera diferente en el código JDBC. Sería hacer que el código JDBC semánticamente defectuoso y no portables por completo. Usted tiene que volver a escribir / reimplementar todo cada vez que desea distribuirlo y / o cambiar a un servidor real RDBMS con más poderes.