Starting with Tomcat 9.0.53 (Update the internal fork of Apache Commons DBCP to 2.9.0 (2021-08-03). Improvements, code clean-up and refactoring.), Commons DBCP started caching the catalog name returned by "getCatalog" (https://github.com/apache/tomcat/blame/9.0.53/java/org/apache/tomcat/dbcp/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).