Conexiones a BDS a través de un Pool de conexiones transparente

Evolución de las APIs JDBC

La versión 3.0 de la API jdbc se divide en dos paquetes

• java.sql
• también conocido como JDBC core API
• está orientado a arquitecturas Cliente/Servidor de dos y tres niveles

• javax.sql
  • también conocido como JDBC Optional Package API
  • está orientado a arquitecturas Cliente/Servidor de n niveles y Arquitectura de empresa

Esta versión incorpora todas las APIs anteriores

• JDBC 1.0 API
  • la selección de la fuente de datos o BDS era esclusiva de los desarrolladores
    • si una aplicación se veía forzada a migrar a otra BDS, se tenía que abrir el código fuente y realizar las modificaciones pertinentes en el código de la Clase que realizaba la conexión a la mueva BDS
• JDBC 1.2 API
  • la selección de la fuente de datos o BDS pasaba de los desarrollador a los administradores de sistemas
• JDBC 2.0 API
  • JDBC 2.1 core API
    • estaba incluido en el JDK.
  • JDBC 2.0 Optional Package API
    • la selección de la fuente de datos javax.sql.DataSource se realiza a través de JNDI y la conexión a una BDS a través de un Pool de conexiones de forma transparente
      • esto sólo se podia realizar descargando un fichero con extensión .jar a parte del JDK y estaba pensado para aplicaciones Web

Funcionamiento interno de un Pool de conexiones

Una aplicación Web que accede a un RDBMS (Relational DataBase Management System) remoto a través de un driver de Tipo 4: 100% Java a través de conexión de Red directa establece una conexión física con una BDS. El establecicimiento de dicha conexión consume CPU, memoria y tiempo.

Una aplicación Web realiza un servicio para varios clientes, si el Sitio Web tiene un nivel de impactos relativamente alto es evidente que una sola conexión con la BDS no es suficiente porque mientras un usuario la está utilizando, pueden haber otros usuarios que estén esperando dicha conexión.

Si queremos que un Sitio Web pueda crear más de una conexión a una misma BDS, lo tendremos que hacer nosotros mismos creando y destruyendo conexiones físicas a la BDS. Esto tiene varios inconvenientes

• en vez de dedicarnos al desarrollo de la lógica de negocio, nos tenemos que involucrar en detalles de bajo nivel de programación de Bases de Datos
• cada conexión como se ha mencionado anteriormente tiene un coste adicional de CPU, memoria y tiempo

Para solventar estos inconvenientes el JDBC Optional Package API nos ofrece un Pool de conexiones o Reserva de conexiones que funciona de forma transparente y no crea un coste adicional a nuestras aplicaciones Web.

El estado inicial de un Pool de conexiones consiste en crear las conexiones físicas iniciales

Cuando un Objeto Java del Servidor Java EE requiere una conexión a través del método dataSource.getConnection(), la fuente de datos javax.sql.DataSource habla con el Pool de conexiones y éste le entrega una conexión lógica java.sql.Connection. Esta conexión lógica finalmente es recibida por el Objeto Java.

Cuando un Objeto Java del Servidor Java EE desea cerrar una conexión a través del método connection.close(), la fuente de datos javax.sql.DataSource habla con el Pool de conexiones y le devuelve la conexión lógica en cuestión.