Resolving 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 WebSphere Application Server 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 administrative 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
- Concurrent deployment of different applications to different application servers or to different application server clusters.
- Concurrent deployment of different applications to the same application server or to the same application server cluster.
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 the wsadmin tool. 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)
// 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()
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
- Use the getConflictDocuments method to determine which configuration files were already saved by another user.
- Issue the AdminConfig.reset() command to discard your changes.
- 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 your 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.