The WebSphere Contrarian

Resolving WebSphere Application Server configuration conflicts

Comments

In each column, The WebSphere® Contrarian answers questions, provides guidance, and otherwise discusses fundamental topics related to the use of WebSphere products, often dispensing field-proven advice that contradicts prevailing wisdom.

Configuration therapy

Let me start out by assuring you that despite the use of the words "resolving conflicts" in the title of this column, I haven’t changed careers and ventured into mediation or some related vocation. In addition, while conversations on any variety of WebSphere Application Server topics could lead to what one could term “spirited debates,” this column doesn’t deal with how to resolve the underlying differences of opinion that lead to discussions of that nature. Rather, the focus here is how to detect and resolve WebSphere Application Server configuration conflicts that can arise from parallel updates of the WebSphere Application Server configuration.

Some time back I authored a column that discussed speeding up application deployment in WebSphere Application Server in order to negate the need to pursue parallel application deployments during a system maintenance window -- which can lead to the very conflicts that are the subject of this column. Further, in the last WebSphere Contrarian, I recommended a dual cell approach for performing maintenance -- both software and hardware -- as a mechanism for minimizing or even eliminating outages for a maintenance window. While the two approaches mentioned previously are still my recommended approaches for performing application maintenance within a given timeframe, if for some reason you find that one or both or these options aren’t viable in your environment, you can employ parallel application deployment as another option by following the steps outlined here.

Before delving into the specific procedure, let’s briefly discuss the embedded function that WebSphere Application Server provides to preclude configuration conflicts.

Whenever a user logs into an administrative client (either the admin console or wsadmin), a different workspace session is used to track the changes. Corresponding to each workspace is a temporary directory that holds all the files touched by the user. The files in the workspace are initially extracted from the WebSphere Application Server cell configuration repository and any changes made by the user are only reflected in the workspace copy until a save occurs. When a save occurs, the WebSphere Application Server configuration management runtime copies the changed files from the workspace back to the master repository, checking first to ensure that the changed files have been neither modified nor saved via another workspace session. As long as two different workspace sessions modify different files, there is no save conflict. When there is a conflict only the first workspace session changes are reflected in the WebSphere Application Server cell configuration repository and the subsequent sessions with conflicting documents will receive a save conflict exception during save. In a shared environment with multiple users, it is always possible to read the configuration, but saving a workspace session might not succeed if another workspace session attempts to save the same files that were modified by the first workspace.

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 which case the WebSphere Application Server configuration management runtime employs a merge algorithm for the serverindex.xml file which supports:

  • 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.

As a result, most typical concurrent or parallel application deployment scenarios can be safely executed without any additional effort on the part of the system administrator. However, there are other application deployment scenarios (such as concurrent deployment to the same application, the same cluster or server, which is not currently handled by the serverindex.xml merge algorithm) as well as other concurrent administration activities involving more than application deployment where configuration conflicts can arise. There are some simple measures you can take to insure against configuration conflicts and to resolve any conflicts for either the supported scenarios or other scenarios 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 any conflicting changes have occurred from another administrative session.

The steps for obtaining the requisite object references and constructing the parameter list required for invocation are shown in Listing 1.

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

You might already be familiar with use of the invoke operation for MBean methods and wonder why the invoke_jmx operation is used instead of invoke. This is because invoke is designed to work with strings and can only manage string format types. In order to use standard Java™ type arrays and other non-strings, the invoke_jmx operation provides the requisite function.

Once the variables and parameter list is initialized, the getConflictDocuments method is invoked. If there are no conflicts, the method will return as shown in Listing 2. Otherwise, if configuration conflicts exist because of changes in another administrative session, the result will be as shown in Listing 3, which lists the XML files that have changed.

Listing 2
// 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/ojaiCell01/nodes/ojaiNode01/serverindex.xml',cells/ojaiCell01/applications/
DefaultApplication.ear.ear/deltas/DefaultApplication.ear/delta-1278791909117', 
... <list abbreviated> ...} 
	
	wsadmin>

Should this occur, you can discard the changes made in your session since the last call to AdminConfig.save() via a call of AdminConfig.reset():

wsadmin>AdminConfig.reset()

If you call the getConflictDocuments method prior to saving and see that there are no conflict documents, there is no guarantee that a save will succeed -- even if called immediately -- because some other session may have modified the same documents between the time of your calling getConflictDocuments and the time that you actually save. However, when a save to the master repository is unsuccessful, you will get a ConfigServiceException exception similar to the one depicted below while updating documents in master repository:

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 this occurs, you can call the getConflictDocuments method to determine which documents have already been saved by some other session. You can then discard your changes by calling AdminConfig.reset(). After discarding, you can then proceed to re-apply your modifications. Assuming that the degree of concurrency to modify the same files is not very high (as well as relying on a bit of luck), a subsequent retry should succeed without conflicts.

Conclusion

Following these steps can help you add the necessary function to detect configuration conflicts that might arise when multiple concurrent administrative actions are employed, and discard updates, if need be, thus avoiding configuration conflicts.

Acknowledgements

Thanks to Ajay Apte, Michael Cheng, Amy Lin, and Vish Venkataramappa for their assistance in preparing this column.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=500203
ArticleTitle=The WebSphere Contrarian: Resolving WebSphere Application Server configuration conflicts
publish-date=07142010