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.

Concernant le déploiement des applications, il est prévu une disposition pour la prise en charge du déploiement simultané. Le déploiement d'applications initié par plusieurs sessions d'espace de travail peut modifier le même fichier serverindex.xml. Dans ce cas, le programme de gestion de la configuration emploie un algorithme de fusion pour le fichier serverindex.xml qui prend en charge :
  • 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)
Une fois que les variables et la liste des paramètres sont initialisés, la méthode getConflictDocuments est invoquée. S'il n'y a pas de conflit, la méthode renvoie le message suivant :
// invoke MBean getConflictDocuments method to obtain a list of any document conflicts 

wsadmin>AdminControl.invoke_jmx(csName,'getConflictDocuments', parms, ptype)
{}
wsadmin>
S'il existe des conflits de configuration dus à des modifications effectuées par un autre utilisateur au cours d'une session de travail, la méthode renvoie un message, semblable au message suivant, qui répertorie les fichiers XML ayant été modifiés :
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>
Dans ce cas, vous pouvez lancer la commande AdminConfig.reset() pour annuler les modifications apportées depuis la dernière exécution de la commande AdminConfig.save() :
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
Si une exception de conflit d'enregistrement apparaît :
  1. Utilisez la méthode getConflictDocuments pour déterminer les fichiers de configuration ayant déjà été enregistrés par un autre utilisateur.
  2. Lancez la commande AdminConfig.reset() pour annuler vos modifications.
  3. 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.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rrun_app_config_conflicts
Nom du fichier : rrun_app_config_conflicts.html