Dit probleem doet zich voor bij de JDBC-verbindingspools en is een probleem dat u krijgt bij alle app-servers die JDBC-verbindingsgroepen gebruiken, niet alleen bij Tomcat. De verbindingspools houden een aantal verbindingen in de pool open voor de volgende aanvraag. Als er door de verbinding naar een PL/SQL-pakket wordt verwezen en opnieuw wordt gecompileerd, zal de volgende aanroep van dat pakket een ORA-06508-fout veroorzaken. Dit heeft invloed op pakketten overal in de oproepstack - niet alleen op het pakket dat u rechtstreeks hebt gebeld.
Om dit op te lossen hebben sommige app-servers (zoals Weblogic) een testmethode die periodiek wordt aangeroepen. Als de test mislukt, wordt de verbinding uit de pool verwijderd of op de een of andere manier vernieuwd. Ik weet niet zeker welk mechanisme Tomcat heeft.
Een andere manier om dit aan te pakken, is door dbms_session.reset_package aan te roepen als de eerste methodeaanroep in uw JDBC-aanroep. Hiermee wordt de pakketstatus van uw sessie gewist. Deze aanpak wordt niet aanbevolen omdat het een prestatieoverhead heeft en alle variabelen binnen het pakketbereik opnieuw worden ingesteld, dus pakketinitialisatieblokken moeten opnieuw worden aangeroepen - nog een prestatiehit.
Als je het probleem hebt en geen manier hebt om slechte verbindingen te verbreken, moet je de hele verbindingspool resetten, aangezien elke verbinding in de pool onder dezelfde uitzondering zal lijden.