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 different JVMs 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.
|