WebSphere® Administration tools, best practices, and recommended use for versions 3.5.x and 4.0.x.

Technote (FAQ)
Problem
What administration clients are available? Can I use multiple instances concurrently of the Administration Console, WebSphere Control Program (wscp), and XML Config?
Solution
What administration clients are available?

There are three administration clients available for use with WebSphere versions 3.5.x and 4.0.x.

  • Administration Console (Java™ GUI)
  • WSCP (based on TCL programming language)
  • XML Config

The administration tools are not considered as one-to-one replacements for each other. This flexible suite of tools compliment each others' functionality. Not all of the administration tools can perform all possible administration tasks. At this time there is a not a comprehensive list of the difference between the tools; use the help functions within the tools as a guide for available functionality.

Can I use multiple instances concurrently of the Administration Console, wscp, and XML Config?

It is possible to have multiple Administration Consoles open at the same time. It is also possible to have the Administration Console open and perform a wscp or XML Config request. You can use several combinations with these three administration tools. There are some limitations in functionality as follows:

  • Stopping and starting differentJVMs at the same time is allowed.
  • Stopping and starting the same JVM from two different administration tools can cause unpredictable results and is not recommended. See the Best practices note below.
  • Any updates that change the repository are processed one at a time. See Best practices note below.

Best practices and recommended use

What occurs when more than one request is made to the repository?

The Administration Console and wscp work in a similar way. The first request locks the entire repository, not only the tables that are affected by the request. All subsequent requests then wait in the connection pool until the repository is released. When the lock is released by the first request, the next request (taken in order of arrival) can access the repository and places a lock against it. This cycle repeats until all requests are complete.

Note that the majority of requests are very small and occur very quickly. If there is a very large request, the waiting requests might time out or seem to be hung. This is because they won't respond until they have their turn with the repository and come back with the request.

Examples

There are two Administration Consoles open in a domain, named AC1 and AC2. Each administration tool's instance has its own cache. Remember this, because it is extremely important.

Situation A:

AC1 sends a request to remove AppServerXYZ. It first looks at the AC1 cache and in this example, AppServerXYZ exists in cache. The request to remove AppServerXYZ is completed against AC1's cache and the repository. The user still sees the application listed in the console until a refresh is done, because the Administration Console does not have dynamic refresh abilities.

Likewise, if AC2 is open prior to the removal of AppServerXYZ, a refresh must be done so that it can synchronize to show any changes made to the repository since the time the console opened or since the last refresh.

As a best practice, the console should be refreshed both prior to and after every update.

Note: In WebSphere versions prior to 4.0.3, the entire tree, as seen in the console, was refreshed upon every refresh request. This caused serious performance degradation. Starting with version 4.0.3 and forward, you must go up one level in the tree from the point of your request to perform the refresh. This is known as parent refreshing and is very efficient from a performance standpoint.

Situation B:

AC1 sends a request to remove AppServerXYZ. It first looks at the AC1 cache and in this example, AppServerXYZ does not exist in cache. It then goes to the repository and finds the application and removes it only from the repository. Again, AC1 must be refreshed once the request is complete so that the change is reflected in the topology of the console.

A different user on AC2 sends a request to update AppServerXYZ, not knowing that it's been removed from AC1. AC2 was not refreshed prior to the request and receives an error on the console.

It's a best practice when an organization has more than one administrator to perform a refresh not only after a change, but also prior to the change request, to ensure that the items in cache are in sync with the repository.

Situations A and B are examples related to the repository. What about wscp and XML Config? Here are the differences for each tool.

wscp

Like the repository, wscp has a cache for each instance and is handled just like the preceding examples; however, wscp does not have a refresh option. Starting with version 4.0.x and forward, the list feature operates as the console's refresh only when the Cumulative WebSphere System Management Fix is applied (see the link near the bottom of this page). So organizations with multiple WebSphere administrators should perform a list prior to changes, and after change requests to ensure that the cache is in sync with the repository.

XML Config

XML Config does not use a cache, it is always a fresh command (single commands) and goes straight to the repository. It's functionality is very straight forward. When a request is made and the repository is locked it displays an error indicating that it is unable to communicate to the repository. If a request is made for an update and the item has been removed from the repository prior to the XML request, it displays an error indicating that it is not able to find the object. There is no refresh command as it's always a single command.

The above is for when XML Config is used in a stand-alone fashion (DOS or Java prompt); however, when used under a wscp prompt or through the Administration Console, it is dependent on the other tools features to function. In this case, a refresh or list is needed both prior to and after requests are made to ensure current information is available to the other tools upon which XML is dependent in these situations.

Cumulative WebSphere System Management Fix

This fix is available for versions 4.0.x and can be downloaded from the WebSphere Application Server's Support Web site:
http://www-1.ibm.com/support/docview.wss?uid=swg24004383

Conclusion

In most situations and as a best practice, we recommend limiting the number of administrators in WebSphere domains. Each administrator must be conscious of the other administrators and perform refresh or list (depending on tool used) prior to and after changes are made to the repository to ensure the cache for their instance is in sync at the time of the request. Unpredictable results, repository corruption, and various types of errors can occur when this best practice is not followed.












Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Administrative Console (all non-scripting)
Operating system(s): Multi-Platform
Software version: 3.5, 4.0
Reference #: 1162155
IBM Group: Software Group
Modified date: 2004-03-09