Le moteur Oracle Data Relationship Management est un environnement multithread et multimachine, et les scripts peuvent être exécutés simultanément sur plusieurs threads et plusieurs machines. Même si vous pouvez créer des valeurs et les stocker dans la portée globale, vous ne devez pas compter sur ce comportement car votre script sera exécuté sur un autre thread où cette valeur globale ne sera pas présente. De même, les valeurs globales ne sont pas mises à jour sur toutes les machines ou instances du moteur Data Relationship Management. En outre, comme Data Relationship Management prend en charge plusieurs versions actives, si vous calculez une valeur pour un noeud et que vous stockez cette valeur dans la portée globale, vous risquez de produire des valeurs incorrectes si un autre script accède à cette propriété pour un autre noeud.
Remarque :
Pour la même raison que vous ne devez pas stocker de variables dans la portée globale, vous devez également éviter de modifier les prototypes d'objet Data Relationship Management intégrés, car vous ne pouvez pas être sûr que les modifications ont été apportées dans tous les threads et toutes les instances du moteur.
Définition des délais d'expiration de script
Pour empêcher les verrouillages excessifs du moteur, les scripts dont l'exécution est trop longue et qui ne renvoient pas de valeur sont interrompus en fonction d'un paramètre d'expiration. Le délai d'expiration de script peut être défini pour chaque définition et validation de propriété.
Le délai d'expiration est propre à chaque contexte d'exécution ; par conséquent, si un export exporte la propriété de script de 100 noeuds et que le délai d'expiration de la propriété est de 30 secondes, cet export peut prendre jusqu'à 50 minutes car chaque noeud peut prendre 30 secondes pour évaluer sa propriété. Cependant, si une propriété de script appelle une autre propriété de script, cela n'augmente pas le délai d'expiration. Par exemple, si PropA a un délai d'expiration de 10 secondes, que PropB un délai d'expiration de 20 secondes et que PropA appelle PropB qui débute ensuite un calcul à longue durée d'exécution, l'évaluation de PropA est interrompue au bout de 10 secondes car son délai d'expiration d'origine a été dépassé.
Prévention des boucles sans fin
Un script qui génère une boucle sans fin (également appelée dépassement de capacité de la pile) est une erreur grave qui peut entraîner l'arrêt inattendu d'un processus serveur. Bien que Data Relationship Management tente d'empêcher l'exécution de ces scripts, vous devez être particulièrement attentif lors de l'écriture de scripts récursifs ou auto-référencés. Testez toujours les nouveaux scripts dans un environnement de développement avant de les déployer vers la production.
Un exemple simplifié de script qui donnera une boucle sans fin est indiqué ci-dessous. Comme le script inclut un appel à lui-même, mais que son exécution n'est jamais interrompue, le moteur qui exécute la fonction finira par s'arrêter en raison d'un manque de ressources. Enfin, comme le script n'appelle jamais le moteur Data Relationship Management, il sera impossible de détecter le dépassement de capacité et d'arrêter le script.
function badFunc(a) { badFunc(a); }
badFunc("oops");Remarques concernant les performances
Pour obtenir des performances optimales, évitez de référencer des propriétés dérivées d'une formule à partir d'un script, et vice versa. Les scripts offrent en général la meilleure opportunité d'optimisation du réglage des performances, comparé aux formules, pour des raisons telles que la compilation Just-In-Time (JIT) du matériel natif, y compris des processeurs 64 bits. Les scripts sont également réglés par le compilateur JIT pour les caractéristiques d'exécution réelles et seront donc exécutés plus rapidement au fil du temps.