Après de nombreux tests, nous avons résolu ce problème. C'est une combinaison de la façon dont nous utilisions le framework Spring et le client oracle et la base de données oracle. Nous créions de nouveaux appels SimpleJDBCCalls qui utilisaient les appels de métadonnées du client oracle JDBC qui étaient renvoyés sous forme de curseurs qui n'étaient ni fermés ni nettoyés. Je considère cela comme un bogue dans le framework Spring JDBC dans la façon dont il appelle les métadonnées mais ne ferme pas le curseur. Spring devrait copier les métadonnées hors du curseur et le fermer correctement. Je n'ai pas pris la peine d'ouvrir un problème Jira avec Spring, car si vous utilisez les meilleures pratiques, le bogue n'est pas affiché.
Ajuster OPEN_CURSORS ou l'un des autres paramètres n'est pas la bonne façon de résoudre ce problème et ne fait que retarder son apparition.
Nous l'avons contourné/réparé en déplaçant SimpleJDBCCall dans un singleton DAO afin qu'il n'y ait qu'un seul curseur ouvert pour chaque proc oracle que nous appelons. Ces curseurs sont ouverts pendant toute la durée de vie de l'application - ce que je considère comme un bogue. Tant que OPEN_CURSORS est supérieur au nombre d'objets SimpleJDBCCall, il n'y aura pas de problème.
