This is working as designed.
Any updates made by a scripting client are kept in a private area or
"workspace" and are only copied over to the real configuration when the
script executes the "AdminConfig save" command. If there are multiple
clients (scripts or browser clients) updating the configuration at the
same time, it is possible that the changes requested by a script cannot be
saved. If this happens, the scripting process throws an exception back to
the user, who can choose to try the updates again. If the save fails, none
of the updates are saved in the configuration. If the save succeeds, all
updates are saved.
If a scripting process ends and no “AdminConfig save” has been performed,
any configuration changes made since the last save are discarded. In the
interactive mode, the user is prompted if unsaved changes are about to be
lost.
An exception to this is made if wsadmin is invoked with the -c option.In
this case, a save is automatically performed if configuration changes are
made.
Under this scheme, the most conservative action a script can take is to
invoke a "save" after every configuration update. This will insure that at
most one command needs to be re-run. This approach is also the most
expensive.
|