Résolution des conflits de configuration d'applications
Dans un environnement partagé comprenant plusieurs administrateurs, il est possible que certains d'entre eux tentent d'effectuer simultanément des mises à jour des mêmes documents de configuration du serveur d'applications. Les informations suivantes devraient vous aider à détecter et à résoudre les exceptions susceptibles de se produire dans ces circonstances.
Chaque fois que vous vous connectez à un client administrateur à l'aide de la console d'administration ou de l'outil wsadmin, une session d'espace de travail unique est créée pour effectuer le suivi des modifications de configuration effectuées. Chaque session d'espace de travail est associée à un répertoire d'espace de travail temporaire. Ce répertoire permet de stocker l'ensemble des fichiers de configuration que vous modifiez au cours d'une session de connexion. Les fichiers qu'il contient sont, au départ, extraits du référentiel de configuration de la cellule ; vos modifications existent dans les copies d'espace de travail de ces fichiers jusqu'à l'enregistrement. Lorsqu'un enregistrement se produit, le programme d'exécution de la gestion de la configuration vérifie que les fichiers de configuration que vous avez modifiés n'ont pas déjà été modifiés et enregistrés par un autre utilisateur, puis copie les fichiers modifiés de votre répertoire d'espace de travail dans le référentiel principal.
Tant que des sessions d'espaces de travail différentes modifient des fichiers de configuration différents, il n'y a pas de conflit d'enregistrement. En revanche, si plusieurs sessions d'espace de travail modifient un ou plusieurs fichiers de configuration identiques, un conflit d'enregistrement se produit et seules les modifications de la première session de l'espace de travail sont reflétées dans le référentiel de configuration de la cellule. Lorsque de futurs utilisateurs tenteront d'enregistrer les modifications dans les mêmes fichiers de configuration, ils recevront une exception de conflit d'enregistrement.
- Le déploiement simultané de différentes applications vers différents serveurs d'applications ou différents clusters de serveurs d'applications.
- Le déploiement simultané d'applications différentes vers le même serveur d'applications ou le même cluster de serveurs d'applications.
En règle générale, les scénarios de déploiement simultané ou parallèle d'applications sont exécutés en toute sécurité par l'administrateur système sans lui demander d'interventions supplémentaires. Toutefois, il existe des scénarios de déploiement d'applications que l'algorithme de fusion serverindex.xml ne peut pas traiter. Par exemple, l'algorithme de fusion serverindex.xml ne gère pas les situations dans lesquelles les modifications de fichier sont déployées de façon simultanée sur la même application, le même cluster ou le même serveur. L'algorithme de fusion ne gère pas non plus les conflits de configuration qui surviennent au cours d'autres activités d'administration simultanées impliquant plusieurs déploiements d'applications.
Obtention des références d'objet requises et construction de la liste de paramètres
Vous pouvez prendre des mesures simples pour vous prémunir contre les conflits de configuration et résoudre les conflits susceptibles de se produire lors de l'utilisation de l'outil wsadmin. Les commandes wsadmin employées pour la détection et la résolution des conflits de configuration s'appuient sur l'obtention d'une référence au bean géré ConfigService et sur l'appel de la méthode getConflictDocuments fournie par ce bean géré, afin de déterminer si les utilisateurs ont fait des modifications conflictuelles au cours de leur session d'espace de travail. (Voir le Javadoc relatif au bean géré ConfigService pour plus d'informations à ce sujet.)
L'exemple de code suivant illustre la tâche d'obtention des références d'objet requises et de construction de la liste des paramètres requise pour invoquer la méthode getConflictDocuments fournie par le bean géré ConfigService :
// get ConfigService MBean reference
wsadmin>cs = AdminControl.queryNames('WebSphere:*,type=ConfigService')
// obtain ObjectName for ConfigService MBean
wsadmin>import javax.management as mgmt
wsadmin>csName=mgmt.ObjectName(cs)
// get session object for the current administrative user session
wsadmin>session=AdminConfig.getCurrentSession()
// manipulate and prepare the administrative session object and
// MBean operation arguments for use
wsadmin>from com.ibm.websphere.management import Session
wsadmin>from jarray import array
wsadmin>parms=array([session], java.lang.Object)
wsadmin>ptype=array(['com.ibm.websphere.management.Session'], java.lang.String)
// invoke MBean getConflictDocuments method to obtain a list of any document conflicts
wsadmin>AdminControl.invoke_jmx(csName,'getConflictDocuments', parms, ptype)
{}
wsadmin>
Listing 3
wsadmin>AdminControl.invoke_jmx(csName,' getConflictDocuments', parms, ptype)
{['cells/cell_name/nodes/node_name/serverindex.xml',cells/cell_name/applications/
DefaultApplication.ear.ear/deltas/DefaultApplication.ear/delta-1278791909117',
... <list abbreviated> ...}
wsadmin>
wsadmin>AdminConfig.reset()
Si vous appelez la méthode getConflictDocuments avant d'enregistrer vos modifications et que vous ne constatez aucun conflit de document, vous n'avez aucune garantie quant à la réussite de l'enregistrement, et ce même si vous lancez immédiatement la commande AdminConfig.save() car les mêmes fichiers de configuration auraient pu être modifiés au cours d'une autre session entre l'appel à la méthode getConflictDocuments et l'exécution de la commande AdminConfig.save().
Si un enregistrement vers le référentiel principal échoue, une exception ConfigServiceException, semblable à celle-ci, s'affiche :
WASX7015E: Exception lors de l'exécution de la commande : "AdminConfig.save()"; exception information:
com.ibm.websphere.management.exception.ConfigServiceException
java.security.PrivilegedActionException:
java.security.PrivilegedActionException:
com.ibm.ws.sm.workspace.WorkSpaceException: RepositoryException
- Utilisez la méthode getConflictDocuments pour déterminer les fichiers de configuration ayant déjà été enregistrés par un autre utilisateur.
- Lancez la commande AdminConfig.reset() pour annuler vos modifications.
- Une fois ces modifications annulées, vous pouvez les appliquer de nouveau aux fichiers de configuration appropriés, puis lancer la commande AdminConfig.save() pour les enregistrer.
La tentative d'enregistrement suivante des modifications a de fortes chances d'aboutir car il est très rare de rencontrer plusieurs conflits de même type au cours de la même session. Si toutefois l'échec devait se reproduire, répétez les actions précédentes puis réenregistrez vos modifications.