déclaration de constantes dans les packages

Bonjour,

Je rencontre systématiquement des erreurs lors de l'exécution de procédures stockées utilisant des constantes définies dans la partie spécification de mes packages PL/SQL :

Code:

---

1 2 3 4

ORA-04061: état existant de package "CPGELDD.PK_DECISION" invalid ORA-04065: package "CPGELDD.PK_DECISION" a été executé, modifié ou supprimé ORA-06508: PL/SQL : unité de programme nommée : "CPGELDD.PK_DECISION" introuvable

---

Voici la manière dont je définis mes constantes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE OR REPLACE PACKAGE pk_decision IS   PARAMETRAGE_DECISION CONSTANT NUMBER := 1; TRAITEMENT_DECISION CONSTANT NUMBER := 2; FINALISATION_DECISION CONSTANT NUMBER := 3;   ...   PS + fonctions   END pk_decision; /

---

J'ai beau recompiler les spécifications et le corps de mon package (ainsi que les dépendances comme le préconise la doc Oracle), le problème est récurrent.

Un truc m'échappe t-il, la déclaration de mes constantes est - elle inexacte ?
Le problème semble résolu lorsque je déclare chaque constante dans le corps de mes procédures, néanmoins cette solution apporte de la redondance :(

Merci de votre aide

Je n'ai jamais noté un souci avec ça. Pourriez-vous fournir un tout petit exemple reproductible de ce que vous faite ainsi que la version de votre base ?
Sinon, je pense que vos soucis sont ailleurs.

L'appel des procédures stockées du package s'effectue depuis une application web Java/JEE (Apache Tomcat).
Détails sur la BD : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP and Data Mining options
Le document suivant m'a permis d'identifier de manière plus précise le problème : http://dbj2ee.blogspot.com/.
Pour résumer, il semble que lorsque je recompile mon package en base de prod son état soit rendu invalide car les connexions clientes déjà actives ont été crées avant le déploiement. La solution serait donc de tuer toutes les connexions en cours ou de redémarrer l'application, chose que je ne peux bien évidemment pas faire.

Citation:

---

The Impact of "ORA-04068" Error
To gauge the impact of ORA-04068, all you have to do is google it. Two of the main impacts are as follows.

1. Most enterprise applications use connection pool in which connections are cached. Now whenever a new package definition has to be deployed, it needs to be recompiled in production. The moment you do that, for all the connections in the connection pool, the state of this package would be invalidated since the package was re-compiled after the connection was obtained (as part of the connection pool initialization sometime earlier.) Note that this is true regardless of whether you changed the state or not, whether you even changed the code or not. The very first time a procedure or function in this package is invoked, it would fail with the "ORA-04058" error. So typically, you have to remember to "flush" the connection pool (meaning discard existing connections and obtain new connections to Oracle.) This typically leads to a downtime in the application deployment. For example, if you are using tomcat and a connection pool within tomcat, you may have to bring down tomcat and bring it back up - so that it re-initializes the connection pool. What if a long-running batch is using one of the connections to execute some logic completely independent of the package that needs to be recompiled? You would either have to wait till the batch completes or kill it during deployment so you can re-initialize the connection pool. As you can imagine, this can be a nightmare in terms of availability of the application.

---

De ce que j'ai compris il faudrait éviter l'utilisation de variables ou constantes globales (qui interfèrent avec l'état du package), et c'est bien embêtant.

J'imagine bien que le déploiement de packages en production d'une manière transparente pour l'utilisateur est possible mais cela dépasse mon domaine de compétences.

Avis aux experts ...

Bonjour,

Citation:

---

Envoyé par micamel

J'imagine bien que le déploiement de packages en production d'une manière transparente pour l'utilisateur est possible mais cela dépasse mon domaine de compétences.

---

Pourtant ca me parait normal. Est-ce que tu déploie une appli (executable, war, ...) pendant que les utilisateurs travaillent ?

Et pourtant c'est possible, mais seulement à partir de la 11gR2, avec 'Edition-Based Redefinition'

Cordialement,
Franck.

J'ai commencé à lire votre lien. Bref, je trouve que le problème est très mal posé: la question n'est pas d'utiliser des packages sans variables globales etc. mais plutôt pourquoi aurez vous besoin de recompiler ces packages tout le temps ?
Une fois que les packages crées et installées vous rédemarez votre pool de connexion et ensuite rien ne change plus.

C'est ce qui arrive quand le développement se fait à l'aveuglette, du fait d'une mauvaise gestion de projet, et que les phases de tests sont négligées ... C'est malheureusement le cas là où je travaille.
D'où la nécessité de repasser des packages en prod quand des erreurs surviennent !

Je vois. Dans notre environnement de développement/qualification nous redémarrons le pool de connexion dans ces casses. Nous n'avons jamais pensé à bannir les constantes de nos packages: c'est horse de question.