For this specific defect, we can see increased DelegatingDatabaseMetaData object counts when DBCP classes are instrumented.
Reasons for this is, Tracers instruments DBCP classes DelegatingStatement, DelegatingConnection, and DelegatingResultSet and Tracers calls the getMetaData() method on DelegatingConnection object to get the information on connection URL or statement parameter or other SQL related metrics.
Due to the bug in DBCP 1.4(DBCP-330) lead to excessive DelegatingDatabaseMetaData objects.
The customer can increase the DBCP version to 1.4.1 but as per previous experience instrumenting DBCP classes may lead to duplicate metrics count issue. So, skipping these classes would be a better approach.
SkipClass: org.apache.commons.dbcp.DelegatingConnection
SkipClass: org.apache.commons.dbcp.DelegatingResultSet
SkipClass: org.apache.commons.dbcp.DelegatingStatement
SkipClass: org.apache.commons.dbcp.DelegatingCallableStatement
SkipClass: org.apache.commons.dbcp.DelegatingPreparedStatement
Above classes are DBCP third-party classes. these classes are wrapper classes on actual SQL Connection, Statement and Resultset classes(JDBC driver specific). APM agent instruments JDBC driver classes to get the metric information(like OracleConnection, OracleStatement). So, I think instrumenting same wrapper classes of DBCP may lead to duplicated metric counts.
for this reason, it's better to skip these classes and with this agent won't miss any metrics since agent instruments actual JDBC classes to get the metrics.
skipping DBCP classes would not compromise on SQL metrics cause getMetaData() method is called on JDBC specific connection object(like OracleConnection or pgConnection) to get metrics information.