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.
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
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