SQLState 42S02 leaves Tomcat JDBC pool connections in service after schema change

Apache Tomcat's built-in JDBC connection pool (org.apache.tomcat.jdbc.pool.DataSource, available since Tomcat 7) exposes rollbackOnReturn to reset transaction state when a connection is returned. After a database schema change, a connection may encounter a table-not-found failure such as SQLState 42S02 or ORA-00942. The pool's validation settings (testOnBorrow, testOnReturn, validationQuery) verify basic connectivity but do not inspect transaction state or schema-change errors.

This creates an unresolved operational question: when an idle pooled connection has raised a schema-change-related error, the pool appears to retain it unless a validation query later fails. It is unclear whether rollbackOnReturn alone is sufficient to mark such a connection for discard, or whether the pool requires an explicit flush or application restart to guarantee that all connections reflect the new metadata.

Does rollbackOnReturn cause the pool to discard connections that previously raised SQLState 42S02? Is there a documented pool attribute that invalidates a connection on specific SQLState or vendor error codes without relying on validation failure? After a DDL statement triggers an implicit commit, does the pool treat the connection as clean even if a later statement fails with a schema-change error?