JSP y Bases de datos

Gonzalo
10 de Enero del 2004
hola a todos.

cada vez que un usuario ejecuta un servlet o una pagina JSP lo que hago es lo siguiente:

1. cargo los drivers
2. me conecto a la base de datos
3. ejecuto las sentencias SQL

la duda es... no es demasiada carga para el servidor cargar los drivers y conectarme a la base de datos una y otra vez cada vez que se ejecuta el servlet o el JSP???

he estado buscando patrones de diseño para aplicaciones J2EE de bases de datos, pero no he encontrado nada.

como creeis que es la mejor forma de hacerlo?

gracias a todos.

Ken
10 de Enero del 2004
Bueno, hay varias aproximaciones a ese tema. Entre ellas están el patrón Soliton y el Pool de Conexiones.

El patrón Soliton consiste en crearte un objeto de ámbito global a la aplicación y al que puedan acceder todos los elementos de la aplicación. De este modo, si te creas un "manejador" de conexiones de acceso global, simplemente tienes que acceder a él (pidiendo su instancia) y que él ejecute el código de acceso a Base de Datos que corresponda.

Ventajas e Inconvenientes: Es efectivo, pero en cuanto el servidor tiene muchas peticiones, la podemos liar, porque es una sóla conexión la que realiza todo el trabajo. Además, hay que sincronizar métodos para evitar problemas de acceso.

El patrón de Pool de Conexiones se le parece mucho, y se basa en crear un objeto de Contexto (algunos usan el árbol JNDI) de tipo DataSource, y acceder a él desde cada elemento de la aplicación.
El objeto DataSource lo que hace es mantener una provisión de conexiones a la Base de Datos (no neceserariamente abiertas) de modo que si un elemento quiere conectar a la Base de Datos, accede al DataSource y le pide una conexión. El DataSource se encarga él solito de administrarlas, si procede, y dejar "en espera" a quien la pide si todas las conexiones están en uso.

Ventajas e Incovenientes: Es un poco más complejo que el patrón Soliton, y requiere una configuración previa del servidor de aplicaciones, para colocar nuestro objeto DataSource en un lugar accesible, pero a la larga es el más efectivo´. Al administrar las conexiones, podemos llegar a un compromiso entre peticiones y conexiones.

Ah! En ambas aproximaciones, no hay que olvidarse de cerrar las conexiones, sentencias, resultsets...etc. Concretamente, con los DataSources, he leído más de una vez desastres y "apagados" por culpa de dejar abiertas conexiones que, por tanto, no se devuelven al administrador.

Espero que esta charla te haya servido. Usa google para buscar información (DataSource, Singleton Pattern...)

Ken