Connection failures after credential expiry for JNDI JDBC DataSource

Answer

No – a JNDI JDBC DataSource does not automatically read new credentials after they expire or are rotated; the username and password are read only when the resource is first bound (at server start or when the JNDI entry is re‑bound).

Confirmed facts

• Tomcat resolves <Resource> elements at startup; the username and password attributes are passed unchanged to the JDBC driver and are not re‑read unless the resource definition is reloaded (via JMX unbind/rebind or a full restart).
• If the supplied credentials have expired, the pool attempts to create new physical connections with those stale credentials; those attempts fail with SQLExceptions such as ORA‑01017 or \"Invalid authorization specification\". Existing pooled connections stay in the pool until they are borrowed, validated (if validationQuery + testOnBorrow/testWhileIdle is enabled), or removed by eviction, after which the pool retries with the same stale credentials unless the resource definition is updated.
• Tomcat 10 adds a factory attribute to <Resource>. A custom javax.naming.spi.ObjectFactory’s getObjectInstance method is invoked on each lookup, allowing it to fetch credentials from a vault, environment variable, or other secret store and return a javax.sql.DataSource (or Connection) without storing clear‑text values in server.xml. The factory does not need to extend DefaultJndiResourceFactory; it only must implement ObjectFactory and return an object assignable to the expected type.

Likely explanation

When credentials are rotated, the only way for the DataSource to see the new values without a full server restart is to cause the resource to be re‑bound (so the factory runs again) or to have the factory obtain fresh credentials on every lookup. If you cannot reload the resource via JMX, a custom factory that reads credentials dynamically is the recommended approach.

Steps for this case

1. Create a class that implements javax.naming.spi.ObjectFactory. In getObjectInstance, read the username and password from your secret source (e.g., HashiCorp Vault, AWS Secrets Manager, or an environment variable), build a javax.sql.DataSource (for example using Tomcat JDBC pool or HikariCP) with those credentials, and return it.
2. Declare the JNDI resource in server.xml (or context.xml) without username and password attributes, specifying the factory class:

   <Resource name='jdbc/myDB'
             auth='Container'
             type='javax.sql.DataSource'
             factory='com.example.VaultDataSourceFactory'
             driverClassName='org.postgresql.Driver'
             url='jdbc:postgresql://dbhost:5432/mydb'
             maxTotal='20'
             validationQuery='SELECT 1'
             testOnBorrow='true'/>

3. Place the factory class (and any dependencies) where Tomcat’s classloader can see it (e.g., $CATALINA_BASE/lib or a shared loader).
4. After deploying, verify that the factory’s getObjectInstance is called on each JNDI lookup by enabling FINEST logging for org.apache.naming.
5. To rotate credentials without a restart, either:
   • Use JMX to unbind then rebind the same JNDI name (this forces Tomcat to invoke the factory again), or
   • Rely on the factory to fetch fresh credentials on every lookup, which makes the resource effectively pick up new credentials immediately.
6. Enable connection validation (validationQuery + testOnBorrow or testWhileIdle) so that if a stale connection somehow remains in the pool, borrowing it will trigger validation failure, the pool will evict it, and a new connection will be created using the current credentials from the factory.

Missing diagnostic detail

Do you have JMX access to unbind/rebind the JNDI resource? If not, the custom‑factory approach is the only way to avoid a full restart.