Lorsque vous exécutez des applications activées avec
l'optimisation client pureQuery,
vous pouvez spécifier l'emplacement où pureQuery Runtime récupère les informations
de configuration d'exécution, ainsi que les informations pureQueryXML. Lorsque vous capturez les données SQL, vous pouvez spécifier l'endroit où les données sont stockées.
Vous créez généralement les fichiers suivants qui sont utilisés au cours
du processus d'activation de l'optimisation client pureQuery
et pendant l'exécution :
- Fichier de propriétés de configurations
pureQuery Runtime
- Fichier pureQueryXML contenant les données SQL utilisées lors de l'exécution
- Fichiers de propriétés de configuration et fichier de propriétés de liaison
- Fichiers pureQueryXML contenant les données SQL capturées
Vous devrez décider de l'emplacement où stocker les propriétés et les données pureQuery. Vous pouvez
utiliser l'emplacement pureQuery Runtime par
défaut ou spécifier un emplacement.
- Système de fichiers local (comportement par défaut)
- Par défaut, pureQuery Runtime
recherche les propriétés et les données sur le système de fichiers local. Sous ce
modèle, les propriétés pureQuery Runtime
pureQueryXml et outputPureQueryXml spécifient
les fichiers contenant les données pureQuery.
Ces deux propriétés peuvent être spécifiées à différents endroits, notamment dans des fichiers nommés pdq.properties
et pdq.appwide.properties.
- Spécifiez un système de fichiers ou un référentiel dans une base de données
- Vous pouvez cependant spécifier que les données pureQuery et les propriétés d'exécution se
trouvent dans le référentiel d'une base de données, dans un système de fichier ou dans une combinaison
des deux. Utilisez les propriétés pureQuery Runtime
finalRepositoryProperties et outputXmlRepository pour
spécifier l'emplacement.
Lorsque vous utilisez une application activée avec
l'optimisation client pureQuery
et que vous stockez les données pureQuery
dans un référentiel, vous utilisez l'utilitaire pureQuery
ManageRepository pour accéder et stocker les données pureQuery dans le référentiel. L'utilitaire ManageRepository peut être utilisé pour créer un référentiel et gérer et entretenir le référentiel.
Le stockage des données et des propriétés pureQuery
dans un référentiel présente des avantages, mais vous devez prévoir en conséquence pour
créer et entretenir le référentiel.
Avantages de l'utilisation d'un référentiel
L'utilisation
d'un référentiel dans une base de données comme magasin central pour les données pureQuery présente différents avantages :
- Les données pureQuery
peuvent être consultées ou mises à jour sans interruption des applications en cours.
- Un référentiel géré de manière centrale permet d'utiliser une seule copie des fichiers de propriétés pureQuery et
des fichiers XML par les applications déployées sur plusieurs serveurs
d'application.
- Une application en cours d'exécution peut être configurée pour rechercher périodiquement
les mises à jour des fichiers de propriétés pureQuery
et des fichiers XML et commencer automatiquement à utiliser les nouvelles données.
- L'autorisation d'accès et de mise à jour des données pureQuery peut être appliquée par la base de données.
- Un administrateur peut examiner plus facilement le fichier pureQueryXML pour inspecter les instructions SQL pour une application et voir les informations d'emplacement du code source pour toute instruction SQL présentant un problème.
Considérations relatives à la configuration du référentiel
Lorsque
vous utilisez une base de données pour stocker des artefacts pureQuery,
vous disposez d'une certaine flexibilité en termes de configuration. Les principaux points de décision sont les suivants :
- Où résidera (résideront) la ou les bases de données contenant les données pureQuery ?
- Comment une application doit-elle réagir quand elle ne peut pas accéder au référentiel au cours de l'initialisation ?
- Une application doit-elle utiliser la fonctionnalité d'actualisation automatique ? Dans ce cas, quel est l'intervalle recommandé pour interroger la base de données DBMQ du référentiel à la recherche des mises à jour ?
- Déterminez l'emplacement de la base de données du référentiel
- Les deux types de données sont les données d'entrée et les données de sortie :
- Données d'exécution et de configuration
pureQuery Runtime (entrée)
- Données SQL capturées
pureQuery (sortie)
Il est possible de configurer l'environnement d'exécution de l'application pour l'utilisation de différents emplacements pour les données d'entrée et de sortie. Vous pouvez localiser chaque type de données dans :
- La base de données où l'application procède aux transactions (la base de données de transaction)
- Une base de données qui s'exécute au même emplacement que le serveur d'applications
- Une base de données distante, séparée de l'application ou du serveur de base de données de transaction
Recommandation par défaut : Créez un seul référentiel dans la base de données de transaction pour les données d'entrée et de sortie. Cela présente deux avantages :
- Simplicité
- Cette approche offre une grande simplicité car elle évite la nécessité de créer et d'entretenir les données dans une base de données distincte.
- Disponibilité
- Les applications peuvent être configurées pour échouer si le référentiel de base de données pureQuery n'est pas disponible
durant l'initialisation. Dans ce type de cas, l'utilisation de la base de données de transaction tend à augmenter la disponibilité de l'application car la base de données de transaction bénéficie normalement d'une excellente disponibilité et d'autres caractéristiques de qualité de service. L'utilisation d'un serveur distinct présentant des caractéristiques similaires augmente les points de défaillance possibles.
Autres considérations relatives à l'emplacement de la base de données :
- Si vous êtes inquiet à l'idée d'augmenter l'activité de la base de données de
transaction ou du réseau en raison de l'actualisation automatique de pureQuery
ou de l'écriture des enregistrements de capture de sortie, envisagez de placer la base de données
du référentiel sur le serveur d'application ou sur un autre serveur.
- Votre site peut également avoir des critères relatifs aux types de données autorisés dans la base de données de transaction. Ces exigences peuvent aussi vous inciter à choisir un serveur distinct pour la base de données.
- Vous pouvez envisager un compromis : placer le référentiel de données d'entrée sur la base de données de transaction et créer un référentiel sur un serveur distinct où stocker les enregistrements de capture de sortie.
- Les configurations qui impliquent une combinaison de données d'entrée dans un référentiel de base de données et de données de sortie sur un système de fichiers local ou distant sont également admises.
- Comportement à adopter lorsque le référentiel est indisponible
- Il est important d'envisager à l'avance la manière dont vous souhaitez que
l'application se comporte au cas où les données pureQuery seraient indisponibles au démarrage
de l'application. La propriété de temps de pureQuery Runtime
repositoryRequired contrôle ce comportement.
Le
paramètre par défaut no incite pureQuery Runtime à revenir au comportement par
défaut pour toutes les propriétés d'optimisation
client pureQuery. Cela signifie que l'application s'exécutera
à l'aide du SQL dynamique. Si cette rétromigration est préférée à l'échec de l'application au démarrage, conservez le comportement par défaut.
Toutefois, dans certains cas, par exemple lors de l'exécution statique des instructions SQL, il peut être problématique, voire impossible, d'exécuter l'application avec les comportements par défaut. Par exemple, l'autorisation de préparer et d'exécuter les instructions SQL en mode dynamique peut ne pas être en place pour tous les utilisateurs de l'application. Si de tels cas se présentent, vous devez spécifier la propriété pureQuery Runtime repositoryRequired avec
la valeur atStartUp.
De même, si la capture des
données de sortie est critique lorsque l'application est en cours d'exécution,
vous pouvez demander à pureQuery Runtime
de vérifier la disponibilité de la base de données de sortie lorsque l'application
démarre en spécifiant la propriété repositoryRequired avec
la valeur forOutput. Dans la plupart des cas, ce paramètre n'est pas nécessaire. Si la base de données de sortie devient disponible durant
l'exécution de l'application, pureQuery
détecte le changement et commence à écrire la sortie.
Si vous souhaitez vous assurer que les bases de données pureQueryXML d'entrée et de sortie sont disponibles, vous pouvez spécifier la propriété repositoryRequired avec la valeur atStartupAndForOutput. Ce paramètre peut aussi être une option utile au cours d'une configuration initiale, pour s'assurer que tout est correctement configuré et éviter d'exécuter l'application pendant une période prolongée avant de découvrir que quelque chose n'a pas été configuré correctement.
- Actualisation automatique des informations pureQuery
- Par défaut, pureQuery Runtime
vérifie la présence de mises à jour des informations pureQuery
pour une version du groupe d'exécution après l'activation de la version du groupe d'exécution.
Si la version du groupe d'exécution est activée et que les données pureQuery de la version du groupe d'exécution
sont à jour, pureQuery Runtime
actualise les données.
Les applications qui reçoivent des mises à jour de maintenance
fréquentes et les infrastructures qui continuent à générer les instructions SQL non capturées
au préalable sont de bonnes candidates pour l'actualisation automatique. L'intervalle spécifié dépendra de la rapidité à laquelle vous souhaitez que les mises à jour soient prises en compte.
Pour de nombreuses applications, une actualisation par jour suffit.
Au cours de
la configuration initiale de l'application, y compris pendant la capture et lors du premier basculement
de dynamique à statique, vous pouvez souhaiter des intervalles plus fréquents, (par exemple,
2 minutes), afin que les modifications soient plus rapidement prises en compte.
Dans certains cas, vous
souhaitez peut-être désactiver la fonction d'actualisation automatique. Si votre application reçoit peu ou aucune mise à jour de maintenance après son déploiement et que la plupart des instructions SQL ont été capturées et liées, il n'est pas vraiment nécessaire de la faire fonctionner en mode de capture continue ni d'activer l'actualisation automatique.
Les propriétés pureQuery Runtime
runtimeGroupActivationCheckInterval et
propertiesRefreshInterval contrôlent
l'actualisation automatique des informations pureQuery
pour les versions du groupe d'exécution :
- La propriété runtimeGroupActivationCheckInterval contrôle le moment où pureQuery Runtime
vérifie les versions de groupe d'exécution activées. La propriété doit être
définie pour qu'elle s'applique à toutes les instances pureQuery Runtime
qui exécutent une machine virtuelle Java.
- La propriété propertiesRefreshInterval peut
être utilisée pour indiquer un intervalle spécifique pour vérifier les mises les mises à jour apportées aux informations pureQuery pour une
version de groupe d'exécution. La propriété peut également être définie de façon à
désactiver toutes les vérifications d'informations pureQuery
mises à jour pour la version du groupe d'exécution, y compris la vérification qui se produit
lorsqu'une version de groupe d'exécution est activée.
Pour plus d'informations sur les propriétés,
voir Propriété runtimeGroupActivationCheckInterval,
et Propriété propertiesRefreshInterval.