On this page:
As soon as you make any update in a form, IceGrid Admin enables two buttons at the bottom of this form: Apply and Discard.
If you navigate to another node without pressing Apply or Discard, the default is Apply: your changes are applied to the in-memory representation of the application definition. However these changes are not stored to the IceGrid registry or XML file until you save the application definition (see below).
Editing a live application () also disconnects this application from the IceGrid registry: updates made by other users are no longer propagated to the Application tab.
Most descriptor sub-trees can be copied and later pasted. Copies are always deep-copies: for example if you copy a node, all the servers on this code are copied, including all the the sub-elements of these servers (object adapters, database environment, services, etc.).
After pasting a sub-tree, you typically need to check and edit the new elements to avoid any duplicate server IDs, adapter IDs etc.
IceGrid Admin performs very little error checking while you are working on an application definition. For example, you may temporarily keep several servers with the same ID, leave some parameters of a template instance unset, or use an undefined variable. All such errors are only detected when you save your application to an IceGrid registry.
There are nonetheless two types of constraints enforced by IceGrid Admin at all times:
If you violate such a constraint, IceGrid Admin prevents you from applying your change.
You save an application definition to an IceGrid registry or an XML file with the menu item
File > Save,
File > Save to File,
File > Save to Registry (Servers may restart),
File > Save to Registry (No Server restart) or with the corresponding toolbar buttons.
Save is equivalent to
Save to Registry (Servers may restart) for a live application, and to
Save to File for a file-bound application.
Saving an application to the IceGrid registry causes the registry to distribute any relevant changes to the affected nodes. In turn, each node applies those changes to its servers. If a server is running at the time of an update, the node may need to stop and restart it, depending on the changes that you make. Consequently, saving to the registry could cause a disruption in service to any clients that are actively using the affected servers.
The following application changes do not require a restart:
All other changes will require a restart. IceGrid Admin provides two versions of the
Save to Registry command, one that allows restarts and one that does not. To avoid accidentally causing any disruption in service, we recommend using the
No server restart option first; this command will fail if any of your updates require a restart. At that point, you can decide whether to force the servers to restart using the other Save command.
If you change a server's configuration properties with
You may discard all your updates by selecting
File > Discard Updates or pressing the corresponding toolbar button.
Discard Updates simply reloads the application from the IceGrid registry or its associated XML file.
If several administrators update the same application definition concurrently, the last save will silently overwrite previous (concurrent) updates.
To avoid this situation, you can acquire an exclusive write access to the IceGrid registry with
File > Acquire Exclusive Write Access. After this exclusive write access is granted, any attempt by another session to save to the IceGrid registry will result in an error: