The WebSphere Contrarian: Resolving WebSphere Application Server configuration conflicts

Any time there’s more than a single administrator for an IBM® WebSphere® Application Sever cell, there’s the possibility of conflicting administrative actions. This installment of The WebSphere Contrarian discusses how to detect and resolve conflicting configuration changes. This content is part of the IBM WebSphere Developer Technical Journal.


Tom Alcott, Senior Technical Staff Member, IBM

Tom AlcottTom Alcott is Senior Technical Staff Member (STSM) for IBM in the United States. He has been a member of the Worldwide WebSphere Technical Sales Support team since its inception in 1998. In this role, he spends most of his time trying to stay one page ahead of customers in the manual. Before he started working with WebSphere, he was a systems engineer for IBM's Transarc Lab supporting TXSeries. His background includes over 20 years of application design and development on both mainframe-based and distributed systems. He has written and presented extensively on a number of WebSphere run time issues.

developerWorks Professional author

14 July 2010

Also available in Chinese

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.

Readers familiar with database concurrency control will recognize the design of workspace conflict resolution as a form of optimistic concurrency control. Optimistic concurrency control permits all read and write operations from multiple transactions to proceed, but performs conflict resolution during transaction commit. When there are few save conflicts, optimistic concurrency provides better performance than other concurrency options, but if there are frequent collisions from different updates of the same record resulting in exceptions and rollbacks, then other concurrency options will provide better performance.

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.

The administrative console makes a provision for reviewing changes prior to saving the configuration associated with any change, but for the reasons noted in this article, any production administration of WebSphere Application Server should be performed solely via scripting.

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 as mgmt


// get session object for the current administrative user session 


// manipulate and prepare the administrative session object and 

// MBean operation arguments for use

wsadmin>from import Session

wsadmin>from jarray import array

wsadmin>parms=array([session], java.lang.Object)

wsadmin>ptype=array([''], 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)
Listing 3
wsadmin>AdminControl.invoke_jmx(csName,' getConflictDocuments', parms, ptype)
... <list abbreviated> ...} 

Should this occur, you can discard the changes made in your session since the last call to via a call of 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: ""; exception information: : 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.


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.


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



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=The WebSphere Contrarian: Resolving WebSphere Application Server configuration conflicts