Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous rencontrons depuis quelque temps cette erreur :
ERROR: cached plan must not change
Voici notre situation :
WAS >> hibernate >> appli >> pool de connexion >> drivers jdbc >> cluster postgresql 9.1.2
L'application génère des prepared statements qui sont persistants dans le cache du driver JDBC.
Si on modifie le DDL (ajout de colonne, modification de la taille d'un champ, etc...) sur une des tables concernées par la requête stockée dans le cache jdbc, on obtient l'erreur cached plan must not change.
Notre solution est de forcer le vidage du cache jdbc en redémarrant le WAS (ce qui n'est pas acceptable puisque le WAS héberge d'autres applications).
La vue pg_prepared_statements ne donne rien, on ne voit pas les prepared statements. Donc on ne peut pas faire de deallocate.
Connaissez vous une solution de contournement à ce problème ?
Merci.
Dernière modification par ruizsebastien (31/12/2012 11:05:15)
Cordialement,
Sébastien.
Hors ligne
La vue pg_prepared_statements montre les requêtes préparées pour votre session, pas pour les autres.
Je ne vois pas de contournement à votre problème. La seule solution est de supprimer les plans en cache si vous faites du DDL.
Guillaume.
Hors ligne
Bonjour Guillaume,
Pour pg_prepared_statements c'est que nous avions compris.
Pour supprimer les plans en cache : comme faire à part relancer le WAS ?
Cordialement,
Sébastien.
Hors ligne
Pour les supprimer, il faut détruire des objets PreparedStamement concernés, côté Java.
Marc.
Hors ligne
Bonjour Marc,
Merci pour votre réponse.
Concrètement comment doit-on faire ?
Cordialement,
Sébastien.
Hors ligne
À priori (mais je ne suis pas développeur java), appeler la méthode close sur les objets PreparedStatement qui posent problème
Marc.
Hors ligne
Merci pour cette réponse.
Nous avons trouver également la méthode clearStatementCache() qui pourrait nous dépanner.
Je mettrais à jour ce file de discussion si nous avons réussi avec une de ces 2 méthodes.
Cordialement,
Sébastien.
Hors ligne
Je pense que le clearStatementCache est une méthode spécifique au driver jdbc d'Oracle.
Marc.
Hors ligne
Bonjour,
Nous ne sommes pas parvenu à vider le cache du driver jdbc avec une méthode java.
Mais nous avons réussi à contourner le problème en tuant les sessions des users transactionnels (pg_terminate_backend) au niveau du cluster après un changement DDL ce qui a pour effet de forcer l'application à ouvrir de nouvelles sessions et donc de demander un nouveau cache au driver jdbc.
Si ça peut aider quelqu'un qui rencontre le même problème...
Merci aux contributeurs pour l'aide apportée et bonnes fêtes de fin d'années à tous !
Cordialement,
Sébastien.
Hors ligne
Pages : 1
