WebSphere Reverse Investor-Resolve configuration conflicts for WebSphere Application server

In each column, websphere® Contrarian investors will answer questions, provide guidance and discuss underlying topics related to the use of WebSphere products, often giving proven recommendations that contradict popular perceptions.

Configuration therapy

Let me first explain to you that although I have used the word "conflict resolution" in the title of this column, I have not changed my career to engage in mediation or related industries. In addition, while discussions about the various WebSphere application Server topics may lead to so-called "spiritual debate", this column does not want to address the fundamental differences in the views that can lead to such debates. Instead, the focus here is how to detect and resolve WebSphere Application Server configuration conflicts that result from the parallel updating of the WebSphere Application server configuration.

In the past, I have written a column that discusses how to speed up application deployment within the WebSphere application Server to avoid the need for concurrent application deployments during the System Maintenance window-which leads to this type of conflict as defined in this column topic. And, in the previous WebSphere contrarian investor article, I recommend using a dual-cell approach to maintenance-software and hardware-as a mechanism to minimize or even eliminate Maintenance window interrupts. The two methods I mentioned earlier are still the recommended way to perform application maintenance within a given time frame. If, for some reason, you find one or two or more options that are not appropriate for your specific environment, you can use a parallel application deployment as another option, as detailed in this article.

Before delving into specific processes, let's briefly discuss the embedded functionality provided by WebSphere application Server to block configuration conflicts.

Readers who are familiar with database concurrency control view the workspace conflict solution as an ideal concurrency control. The ideal concurrency control allows all read and write operations from multiple transactions, but the conflict resolution is executed during transaction commits. Ideal concurrency control provides better performance than other concurrency options when save conflicts are low, but other concurrency options provide better performance if different updates to the same record often have conflicts that cause exceptions or rollback.

Whenever a user logs on to an Administrator Client (Admin console or wsadmin), a different workspace session is used to track changes. corresponding to each workspace is a temporary directory that holds all files that the user has contacted. The files in this workspace are originally extracted from the WebSphere application Server unit configuration repository and all changes made by this user are reflected only in the copy of the workspace until a save occurs. When the save occurs, the WebSphere application Server configuration Management runtime will be copied back to the home repository from the changed files in this workspace, but first check to make sure that the changed file has not been modified or saved by another workspace session. As long as the two workspace sessions modify different files, there is no save conflict. When there is a conflict, only changes to the first workspace session are reflected in the WebSphere application Server unit configuration repository, while subsequent sessions with conflicting documents receive a save conflict exception during the save. In a shared environment with multiple users, this configuration can always be read, but saving this workspace session may not be successful if another workspace session attempts to save the same file that has been modified by the first workspace.

For application deployment, a special configuration is made to support concurrent deployment of the application. Application deployments initialized with different workspace sessions can modify the same Serverindex.xml file, in which case the WebSphere application Server configuration Management Runtime is Serverindex.xml The file uses a merge algorithm that 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 the same application server cluster.

Before you save the configuration associated with any of the changes, the management console makes a setting to view the changes, but for the reasons mentioned in this article, any production management for the WebSphere application Server should be executed entirely through scripting.

As a result, most typical concurrent or parallel application deployment scenarios are safe to perform without any additional effort from the system administrator. However, there are other application deployment scenarios, such as concurrent deployments to the same application, the same cluster or server, which are not currently handled by the Serverindex.xml merge algorithm, and other concurrent management actions that involve more than just application deployment, and therefore have the potential for configuration conflicts. There are some simple measures that can be used to ensure that there are no configuration conflicts and resolve all conflicts for some of the supported scenarios or other scenarios when using Wsadmin.

The wsadmin command used to configure conflict detection and resolution relies on obtaining a reference to the Configservice Mbean, and then invokes the Getconflictdocuments method provided by the MBean to determine whether conflicting changes have occurred from another management session.

The steps to get the desired object reference and to construct the list of parameters required for this call 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)