Ayer estuve en un cliente que tenía un problema con una aplicación Java que se ejecutaba en Tomcat 5.5 sobre RHEL5U2 64bits con Java 1.5 64bits contra Oracle 9.2.0.4 RAC, atacando listeners en modo shared_server.
El problema estaba en que la aplicación no conectaba a la base de datos. Al reiniciar el tomcat y establecer las conexiones iniciales del pool de conexiones de Tomcat, se quedaba colgado esperando indefinidamente y el Tomcat no terminaba de arrancar. El cliente aseguraba que la aplicación llevaba así configurada y funcionando desde hacer dos meses. Desarrollé un cliente sencillo en Java, para detectar qué nodo de la BBDD se quedaba colgado, porque unas veces se comportaba de esta manera y otras veces arrancaba con normalidad. Este mismo cliente me sirvió para descartar que el problema estaba en el uso del pool de conexiones de Tomcat. El uso del pool de conexiones de Oracle, requería modificar el código fuente de la aplicación usando springs. Anteayer pasó lo mismo y terminaron reiniciando la BBDD, tras lo cual todo volvió a funcionar.
Ayer insistí en depurar un poco más porque esto sólo afectaba a las conexiones Tomcat y JDBC, y sin embargo, SQLPLUS, TOAD, Oracle Forms etc, no tenían ningún problema en conectar usando los mismos listeners que con JDBC no conseguíamos conectar.
Lo primero que hice fue mirar la matriz de compatibilidad de Oracle en la nota 401934.1 de metalink. Estábamos en matriz: Con esta combinación podíamos usar ojdbc5.jar del instantclient 11.1 u ojdbc14.jar del 10.2. La aplicación estaba usando ojdbc14.jar de la versión 10.2.0.1 por lo que decidimos conservar la misma versión pero actualizada a 10.2.0.4 y descargando de nuevo la versión de 64bits, por mantener la compatibilidad con springs. Tras realizar distintas pruebas usando thin driver, terminamos configurando oci driver, y entonces sí todo funcionaba perfectamente.
La conclusión que debemos sacar de esta experiencia, es que ante aplicaciones Java lo primero que debemos hacer es revisar nuestra matriz de compatibilidad JDBC-Java-Oracle, y lo segundo es usar OCI en vez de THIN siempre que sea posible.
Java DataBase Connectivity, más conocida por sus siglas JDBC, es una API que permite la ejecución de operaciones sobre bases de datos en lenguaje Java. Esta API nos permite independencia en la aplicación (código) de la base de datos a la que se accede y, vienen a ser una colección de interfaces y clases Java, que implementan un manejador o driver de conexiones hacia un servidor de base de datos. Existen varias formas de implementar este manejador o driver, y la propia Oracle ofrece tres posibilidades:
- Thin driver, enteramente escrito en Java, provee una implementación en TCP/IP de Oracle SQL*Net/Net8, independiente del sistema operativo. No requiere de más software de Oracle instalado en el equipo que lo use. Se usa en el cliente de BBDD o servidor de aplicaciones.
- OCI driver (Oracle Call Interface), es una implementación mitad en Java y mitad en código nativo C (Java hace de Wrapper entre la aplicación y las llamadas en C), que provee una implementación completa de Oracle SQL*Net/Net8, además de IPC, named pipes y SPX/IPX, dado que se apoya en el cliente pesado de Oracle que además, es obligatorio tener instalado. Necesita tener un fichero
tnsnames.oraen$ORACLE_HOME/network/admin/. Se usa en el cliente de BBDD o servidor de aplicaciones. - KPRB driver es utilizado para escribir en Java procedimientos almacenados, funciones, triggers ... Ofrece acceso a la conexion activa por lo que no es necesario crear ninguna conexión adicional. Se usa en el servidor de BBDD.
No hay comentarios:
Publicar un comentario