Pregunta

Me estoy tomando la decisión de una base de datos embededded en una próxima aplicación servlet de Java. Estoy a dos contendientes finales:. SQLite con SQLiteJDBC "puro Java" conductores vs Java DB (también conocido como Derby)

Aquí es mis criterios asesinas: La aplicación debe ejecutarse en cualquier sistema operativo que soporte Java, específicamente tenemos Solaris, CentOS, Ventanas x86 y x64 de Windows hosts que será todo lo que tenga que ejecutar la aplicación. Y la instalación debe implicar nada más que copiar el archivo de la guerra a la carpeta de implementación del servidor de destino y dejar que el servidor haga el resto (que no es nada más que la copia de un zip para el servidor de destino y luego dejar que el descomprimir servidor y ejecutar la aplicación). No debe haber al rededor binarios nativos como parte de la instalación, y ninguna lógica de configuración adicional. (Que en realidad no es mi obligación, que es la empresa de, para todas las aplicaciones basadas en servlets, pero sí me gusta).

Sé que Derby (Java DB) cumple los criterios anteriores. Yo he hecho una vez o dos veces. Pero me gusta mucho la arquitectura solo archivo de SQLite y el hecho de que la comunidad SQLite es de aproximadamente 20 veces mayor que el de Derby. También tengo el temor de que Oracle va a matar a Derby algún día, ya que ahora tienen algo así como cinco productos de base de datos que compiten bajo su paraguas y que no pueden durar para siempre. Derby será probablemente la primera baja cuando comienza el servicio de limpieza.

Por lo tanto, yo estaba buscando en SQLiteJDBC, que afirma contar con controladores JDBC de Java "puros" para SQLite. Ahora, lo entendería "Java puro" en el sentido de que no existen dependencias del sistema operativo o bibliotecas adicionales, que se puede ejecutar el controlador en cualquier JVM en cualquier sistema operativo. Por lo tanto, ir a buscar el archivo jar con los controladores de Java puro. Y siendo la curiosa especie, miro dentro de ella. Entonces noto que contiene 4 archivos en la raíz con extensiones ".lib", de la siguiente manera:

Linux-amd64.lib
Linux-x86.lib
mac-universal.lib
ganar-x86.lib

Ok, así que, ¿qué pasa con eso? Son estos como bibliotecas nativas para el llamado sistema operativo de? Si es así, ¿puedo asumir este controlador Java puro sólo se ejecutará en una plataforma con un archivo lib apropiado en el frasco? Si ese es el caso, lamentablemente tendrá que tomar SQLite fuera de la lista de candidatos, porque Winx64 y Solaris son nuestros dos OS más importante está aquí.

O tal que he malinterpretado y el conductor Java puro realmente es puro Java y que se ejecutará en cualquier JVM?

Todas las respuestas dan la bienvenida !!!

Gracias de antemano, John

¿Fue útil?

Solución

Si he entendido bien, sí SQLiteJDBC es un controlador JDBC de tipo 4, pero todavía requiere una cierta integración binario nativo para la plataforma operativa de acogida desde SQLite es todavía una solución basada en C y no tiene una capa de integración de la red / protocolo como SQL * Net para Oracle por lo que yo sé. La página de inicio SQLiteJDBC menciona una aplicación "NestedVM" para cualquier lenguaje soportado por GCC, por lo que parece posible desplegar multiplataforma donde quiera que haya entorno de ejecución de GCC. No hubo mención de Solaris sin embargo.

Otros consejos

http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC -. proporciona una implementación Java puro, aunque no siempre utilizan el .lib archivos cuando sea posible, ya que son más rápidos

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top