[
https://issues.apache.org/jira/browse/DBCP-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismael Teijeiro Flórez updated DBCP-583:
----------------------------------------
Description:
Commons DBCP started caching the catalog name returned by {{getCatalog}} (
[https://github.com/apache/commons-dbcp/blob/922eb2685ff64bdb27607ceecbe333330e5be4c0/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java]).
This can cause the method to return incorrect values after using a pooled
connection to execute a SQL command that effectively changes the catalog of the
connection.
The motivation for executing a SQL command that changes the catalog of a
connection instead of calling {{setCatalog}} is that some vendors provide
commands that allow for "new connections" to happen on an already established
connection (i.e. commands that allow connecting to a different catalog, with a
different user). Commons DBCP doesn't offer a way to clear the cache of a
connection when something like this happens, which can lead to incorrect
results.
We also think that calling the {{close}} method on the connection should invoke
the {{clearCachedState}} method (as it is called when a transaction ends:
[https://github.com/apache/commons-dbcp/blob/922eb2685ff64bdb27607ceecbe333330e5be4c0/src/main/java/org/apache/commons/dbcp2/managed/ManagedConnection.java]).
was:
Commons DBCP started caching the catalog name returned by "getCatalog" (
https://github.com/apache/commons-dbcp/blob/922eb2685ff64bdb27607ceecbe333330e5be4c0/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java).
This can cause the method to return incorrect values after using a pooled
connection to execute a SQL command that effectively changes the catalog of the
connection.
The motivation for executing a SQL command that changes the catalog of a
connection instead of calling "setCatalog" is that some vendors provide
commands that allow for "new connections" to happen on an already established
connection (i.e. commands that allow connecting to a different catalog, with a
different user). Commons DBCP doesn't offer a way to clear the cache of a
connection when something like this happens, which can lead to incorrect
results.
We also think that calling the "close" method on the connection should invoke
the "clearCachedState" method (as it is called when a transaction ends:
[https://github.com/apache/commons-dbcp/blob/922eb2685ff64bdb27607ceecbe333330e5be4c0/src/main/java/org/apache/commons/dbcp2/managed/ManagedConnection.java]).
> The "DelegatingConnection.getCatalog" method can return incorrect cached
> values
> -------------------------------------------------------------------------------
>
> Key: DBCP-583
> URL: https://issues.apache.org/jira/browse/DBCP-583
> Project: Commons DBCP
> Issue Type: Bug
> Affects Versions: 2.9.0
> Reporter: Ismael Teijeiro Flórez
> Priority: Major
>
> Commons DBCP started caching the catalog name returned by {{getCatalog}} (
> [https://github.com/apache/commons-dbcp/blob/922eb2685ff64bdb27607ceecbe333330e5be4c0/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java]).
> This can cause the method to return incorrect values after using a pooled
> connection to execute a SQL command that effectively changes the catalog of
> the connection.
> The motivation for executing a SQL command that changes the catalog of a
> connection instead of calling {{setCatalog}} is that some vendors provide
> commands that allow for "new connections" to happen on an already established
> connection (i.e. commands that allow connecting to a different catalog, with
> a different user). Commons DBCP doesn't offer a way to clear the cache of a
> connection when something like this happens, which can lead to incorrect
> results.
> We also think that calling the {{close}} method on the connection should
> invoke the {{clearCachedState}} method (as it is called when a transaction
> ends:
> [https://github.com/apache/commons-dbcp/blob/922eb2685ff64bdb27607ceecbe333330e5be4c0/src/main/java/org/apache/commons/dbcp2/managed/ManagedConnection.java]).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
