Una de mis fuentes favoritas de expedientes X en el desarrollo aplicaciones es la integración con base de datos en entornos de pruebas y producción. Me ha pasado de todo, uno de los peores fue un firewall que mataba en silencio conexiones inactivas. Pero la gran mayoría han sido problemas aparentemente sin explicación por culpa de la versión del driver JDBC utilizado. Saber qué driver JDBC instalar en tu servidor de aplicaciones no debe tomarse a la ligera.
En las grandes organizaciones es bastante habitual encontrarse con Oracles 8 y 9, cuyas inversiones aún están amortizándose. No es que sea una queja, son robustas bases de datos con unas fantásticas herramientas.
A la hora de definir el entorno de desarrollo preguntas
Ésta es la teoría. A la hora de ponerla en práctica, te vas a la página para descargar los drivers JDBC Oracle y te encuentras con que existe un enlace para cada cada gran versión de Oracle Database. La impresión que te llevas es que si tienes, pej un Oracle 9.2.0.6, tienes que seleccionar el enlace de Oracle 9.2.x drivers. Bueno, esto es correcto pero sólo en parte.
Si consultamos la matriz de interoperabilid entre drivers y database veremos que todas las versiones de los drivers JDBC funcionan para todas las versiones de Database desde la versión 9.2.x. Para más información, en especial para versiones anteriores, se puede consultar la FAQ de JDBC.
Entonces, ¿por qué tanta versión?
Las diferencias entre las versiones del driver JDBC radican principalmente en las funcionalidades JDBC que implementan y en las versiones Java bajo las que funcionan.Así por ejemplo, la versión 11 del driver JDBC thin Oracle sólo está disponible para Java 5 y 6, si quieres usar auto-generated keys tendrás que usar una versión 10 o superior y si quieres tener soporte completo para tipos LOB (CLOBs y BLOBs) olvídate del classes12.jar.
Lo más recomendable es utilizar la última versión del driver JDBC compatible con tu versión de Java.
Quiero creer
Hasta aquí la parte sencilla. Las sorpresas vendrán cuando tu aplicación pase de tu entorno controlado de desarrollo a uno de pruebas del cliente y empiecen a sucederse los expedientes X con tareas de acceso a la base de datos.Mi consejo es comprobar la versión del driver JDBC instalada en el servidor de pruebas. Si es una versión antediluviana seguramente ya tienes la causa. La solución es convencer al responsable de Sistemas del cliente de actualizar el driver JDBC pero esto será una dura prueba para tus habilidades de negociación...
el problema principal es no saber que version hay en produccion y no tener un entorno de preproduccion totalmente exacto al de produccion.
A todos nos gustan las bondades de la JDK 1.6 pero es posible que si haces una aplicacion para escritorio, el usuario si tiene un cliente oracle de la 8.1 tenga instalado el JDK 1.3 y tu fabulosa aplicacion no funciona.
En produccion todavia tengo el JDK 1.4.2 y estoy esperando para pasar a la 1.5 y añadir algunas mejoras, pero nuestro entorno de desarrollo jamas es mas elevado que el servidor de produccion.
La verdad es que el java no gestiona bien sus subidas de version y la mania de los programadores de utilizar las ultimas funcionalidades dan sorpresas.
Trabaja siempre con el driver que se utiliza en este momento en produccion, dejando preparado las mejoras para cuando se cambie de driver.
Anónimo
26 de agosto de 2008, 20:12Batch4j, eso es lo ideal sí, cuando tienes totalmente definido el entorno de producción, que además es único y hasta te pasan el driver JDBC. En ese caso, usar cualquier otro driver no es ya una manía, es simplemente un suicidio.
Pero no todos los proyectos son de ese estilo. A veces el entorno de producción es algo más abierto (Oracle 9 o superior + Java 1.4 o superior) o existen múltiples posibles entornos de producción (MySql 5 y Oracle 11).
El objetivo del post era arrojar un poco de luz al jaleo de drivers JDBC que tienen montado en Oracle y en ningún caso pretendía dar alas a los fanáticos de la última versión ni que se pase de lo instalado en el entorno de producción, todo lo contrario. Repito, en un proyecto de cliente, todo lo que no sea ceñirse rigurosamente a las versiones utilizadas en su entorno de producción es un suicidio.
PD: He hecho una mini actualización del post, gracias por tu comentario.
jcesarperez
27 de agosto de 2008, 0:38Como se puede compilar con la version 1.4 y ejecutar en versiones superiores si sabes la version minima es facil compilas con la minima.
Tengo un software compilado con la 1.2 que ejecuta en 1.3, 1.4, 1.6 ...
Anónimo
7 de diciembre de 2008, 12:28