java - from - Comportamiento de conexión: DriverManager.getConnection() y DataSource.getConnection()
java datasource pool (3)
Si obtengo un objeto de conexión usando DriverManager.getConnection() y DataSource.getConnection() , ¿cómo difieren en el comportamiento cuando se llama a .close() en esos objetos?
Antes de la llamada al método .close() , obtuve objetos Statement y ResultSet relevantes de estas dos conexiones diferentes. Poco después de obtener estos dos objetos, si digo connection1.close() (a través de DriverManager.getConnection() ), anulará el objeto de conexión y no se supone / tengo permiso para acceder a los objetos Statement y ResultSet relevantes. ¿Corrígeme si estoy equivocado?
Segundo escenario, ahora si digo connection2.close() (a través de DataSource.getConnection() ), simplemente lo devuelve al grupo. Pero la conexión aún está en vivo. ¿Podré acceder a los objetos Statement y ResultSet asociados?
connection1.close () (a través de DriverManager.getConnection ()),
Esto cerrará la conexión física establecida a la base de datos y todos los recursos a saber. Conjunto de resultados, declaración, conexión son liberados. Por lo tanto, no puede acceder a ellos una vez que se cierra la conexión.
connection2.close () (a través de DataSource.getConnection ())
Esto depende de la implementación de DataSource, por lo que no es necesario que el comportamiento sea uniforme en las diferentes implementaciones de DataSource. Además, dentro de una implementación de DataSource determinada, el ciclo de vida real de la conexión depende de varios otros parámetros, por lo que se recomienda encarecidamente no diferenciar esta conexión de la obtenida a través de DriverManager.
Si realmente desea que los datos contenidos en el ResultSet estén disponibles después de que se cierren el enunciado y la Connection , puede echar un vistazo a CachedRowSet si eso se ajusta a su uso.
El almacenamiento en caché del lado del cliente puede depender de que el controlador utilizado para la conexión no esté seguro. Pero algunos controladores específicamente le impiden usar una declaración o conjunto de resultados una vez que se ha cerrado la conexión. Otros mantienen los resultados en el lado del cliente
Si asumimos un DataSource (básico) (es decir, uno que no hace la agrupación de conexiones), entonces obtiene una conexión física que es la misma que la obtenida de DriverManager (algunos controladores incluso usan DriverManager de forma interna desde DataSource, o un DataSource de DriverManager). Entonces esas conexiones se comportarán de manera idéntica.
Ahora, si suponemos un DataSource que proporciona la agrupación de conexiones, el DataSource usa un ConnectionPoolDataSource (o un mecanismo interno similar) para obtener una PooledConnection . Este PooledConnection administra la conexión física real a la base de datos.
Cuando un usuario solicita una conexión desde el DataSource, el DataSource registrará una conexión compartida y le solicitará una Connection . El PooledConnection luego creará una conexión lógica que usa o envuelve la conexión física (por ejemplo, usando un Proxy). El DataSource devolverá esa conexión lógica al usuario.
Para el usuario, la conexión lógica debe comportarse de forma idéntica a una conexión física en todos los aspectos. Por lo tanto, cuando un usuario cierra la conexión, esa conexión lógica y todos los objetos JDBC dependientes se cerrarán y se comportarán de forma idéntica a un cierre de conexión física.
JDBC 4.1 sección 11.1 dice:
La agrupación de conexiones es completamente transparente para el cliente: un cliente obtiene una conexión agrupada y la utiliza de la misma forma que obtiene y utiliza una conexión no compartida.
Y la sección 11.4:
Si la aplicación intenta reutilizar el identificador lógico, la implementación de Connection arroja una SQLException.
y
Para un objeto PooledConnection determinado, solo será válido el objeto de Conexión lógica producido más recientemente. Cualquier objeto de conexión previamente existente se cierra automáticamente cuando se llama al método PooledConnection.getConnection asociado.
En el fondo, sin embargo, cuando la conexión lógica está cerrada, PooledConnection indicará a DataSource que está disponible para su reutilización, y DataSource la devolverá al grupo de conexiones, o cerrará PooledConnection (que cierra la conexión física) si ya no necesita la conexión.
El DataSource también puede revocar forzosamente una conexión de un usuario (por ejemplo, cuando una conexión se retira demasiado tiempo, etc.), pidiendo a PooledConnection que cierre la conexión lógica.