Tomcat leak prevention vs third‑party JDBC drivers: classloader isolation on redeploy

Goal

Determine whether Tomcat’s built‑in leak prevention (JreMemoryLeakPreventionListener and the clearReferences* attributes) reliably isolates a web application’s classloader when third‑party JDBC drivers and thread‑local caches are present.

Constraints and uncertainty

• JreMemoryLeakPreventionListener pre‑loads known JDK classes at server start, but drivers loaded by the webapp classloader after listener initialization may remain registered.
• clearReferencesJdbc (default true) attempts to deregister drivers, yet it only works for drivers visible to the common classloader and can fail if a driver re‑registers in a static block.
• clearReferencesThreadLocals (default false in Tomcat 10.1) clears thread locals created by webapp classes but cannot clean those created by parent‑classloader libraries; aggressive clearing may break frameworks that expect thread locals to survive.
• Behavior of these mechanisms changed between Tomcat 8.5, 9.0, and 10.1, so version‑specific defaults matter.

Open questions

1. Does the combination of JreMemoryLeakPreventionListener and clearReferencesJdbc guarantee driver deregistration for drivers loaded solely by the webapp classloader?
2. Under what conditions does clearReferencesThreadLocals safely clean thread‑local caches without causing NullPointerExceptions in libraries such as Spring’s RequestContextHolder?
3. Which Tomcat version‑specific defaults should be explicitly set to achieve reliable classloader release on redeploy?