Network Deployment (Distributed operating systems), v8.0 > Reference > Administrator best practices


Resolve application configuration conflicts

In a shared environment with multiple administrative users, it is possible that different administrative users might attempt concurrent updates of the same WAS configuration documents. The following information should help you detect and deal with any exceptions that might occur if multiple administrative users attempt to concurrently update the same configuration documents.

Whenever you log into an administrative client using either the admin console or wsadmin tool, a unique workspace session is created to track any configuration changes that are made. For each workspace session, a temporary workspace directory is associated with each workspace session. This directory is used to store all of the configuration files that you change during a login session. The files in this directory are initially extracted from the cell configuration repository, and your changes only exist in the workspace copies of these files until a save occurs. When a save occurs, the configuration management runtime makes sure that the configuration files you changed have not already been modified and saved by another user, and then copies the changed files from your workspace directory back to the master repository,

As long as different workspace sessions modify different configuration files, there is no save conflict. However if multiple workspace sessions modify one or more of the same configuration files, a save conflict occurs, and only the first workspace session changes are reflected in the configuration repository for the cell. When subsequent users attempt to save the changes to the same configuration files, they receive a save conflict exception

With regard to application deployment, a special provision is made for supporting the concurrent deployment of applications. Application deployment initiated by different workspace sessions can modify the same serverindex.xml file. In this situation, the configuration management runtime employs a merge algorithm for serverindex.xml which supports:

Typically, concurrent or parallel application deployment scenarios are safely executed without any additional effort on the part of the system administrator. However, there are application deployment scenarios that the serverindex.xml merge algorithm does not handle. For example, the serverindex.xml merge algorithm does not handle situations where file changes are concurrently deployed to the same application, the same cluster or the same server. The merge algorithm also does not handle configuration conflicts that arise during other concurrent administration activities that involve more than application deployment.


Obtaining the requisite object references and constructing the parameter list

There are some simple measures you can take to ensure against configuration conflicts, and to resolve any conflicts when using wsadmin. The wsadmin commands that are employed for configuration conflict detection and resolution rely on obtaining a reference to the ConfigService MBean, and then invoking the getConflictDocuments method provided by that MBean to determine if users have made conflicting changes to a file during their workspace session. See the Javadoc for the ConfigService MBean for more information about this Mbean.

The following code example illustrates how to obtain the requisite object references and construct the parameter list that is required to invoke the getConflictDocuments method that the ConfigService MBean provides: 

// 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)

After the variables and parameter list is initialized, the getConflictDocuments method is invoked. If there are no conflicts, the method returns the following message: 

// invoke MBean getConflictDocuments method to obtain a list of any document conflicts

wsadmin>AdminControl.invoke_jmx(csName,'getConflictDocuments', parms, ptype)
{}
wsadmin>

If configuration conflicts exist because of changes another user made during a work session, the method returns a message, similar to the following message, that lists the XML files that have changed: 

List 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>

In this situation, you can issue the AdminConfig.reset() command to discard the changes that you made since the last AdminConfig.save() command was issued: 

wsadmin>AdminConfig.reset()

Even if you call the getConflictDocuments method prior to saving your changes, and see that there are no conflict documents, there is no guarantee that a save will succeed, even if you immediately issue the AdminConfig.save() command because some other session might have modified the same configuration files between when you call the getConflictDocuments method, and when you issue the AdminConfig.save() command.

When a save to the master repository is unsuccessful, you get a ConfigServiceException exception that is similar to the following exception: 

WASX7015E: Exception running command: "AdminConfig.save()"; exception information:
com.ibm.websphere.management.exception.ConfigServiceException
java.security.PrivilegedActionException:
java.security.PrivilegedActionException:
com.ibm.ws.sm.workspace.WorkSpaceException: RepositoryException

If you receive a save conflict exception:

  1. Use the getConflictDocuments method to determine which configuration files were already saved by another user.
  2. Issue the AdminConfig.reset() command to discard your changes.

  3. After discarding these changes, you can reapply your changes to the appropriate configuration files, and issue the AdminConfig.save() command to save these changes.

The subsequent attempt to save changes is likely to succeed because it is not typical to experience multiple save conflicts during the same session. However, if this subsequent save attempt is not successful, repeat the preceding actions, and save your changes again.
Update enterprise application files
ConfigService MBean

+

Search Tips   |   Advanced Search