The Deploy Transaction
The deploy command initiates a transaction with the goal that all clients begin using the modified realm definition.
Dialog Options
At each juncture, the deploy transaction dialog offers a subset of these options, as appropriate:
- Cancel
- Cancel the deployment or test. The transaction rolls back. The realm server and its clients discard the modified realm definition, and continue as they were, using the realm definition of the previous deployment.
- Test
- Attempt to execute only step 1 of the deploy transaction, and display the results. When the test completes, a dialog box again offers a subset of these options.
- Deploy
- Attempt to execute all the transaction steps, and display the results.
If a test completes step 1 with all clients accepting, you may immediately continue to the remaining steps of the transaction by selecting this option.
- Force Deploy
- If a test or deploy attempt completed with any clients unable to accept the deployment, and you determine that it is appropriate to continue, then you may force the deployment to the clients that can accept it.
The transaction proceeds to step 2. When the transaction commits, the realm server stores the modified realm definition in the database, and instructs the clients that can accept it to begin using it.
Clients that cannot accept it continue running as they were, however, problems might arise as those clients interact with updated clients.
Steps of the Deploy Transaction
Step numbers correspond to numbered arrows in the diagram Realm Definition Storage and Transitions.
- Test. The server tests the workspace realm definition against all connected client application processes. (If the realm server is a primary with satellites, see
Satellite Servers Recursively Test Their Clients.)
The server also tests the connection to its backup server (if one is configured). If it is disconnected, then the server rolls back the transaction.
Each client tests the modified realm definition to determine whether it can accept the modifications and continue running. Each client reports its response to the realm server (see Responses to Deployment Tests). The server combines the answers from its clients, and reports a single consolidated answer (see Consolidation of Responses to Deployment Tests).
If the consolidated test succeeds, or an administrator forces the deployment to continue, then the server proceeds to the next step. (See Successful Test.) Otherwise the server rolls back the transaction.
- Write. The server writes the modified workspace realm definition to the realm server database.
- Activate. The server instructs client application processes to begin using the modified realm definition.
- Archive. The server copies the deployment package from the workspace directory to a deployment archive directory.
- Release. The server releases the realm modification lock.
Responses to Deployment Tests
This table lists the possible responses after testing a realm update deployment, from most favorable to least favorable.
For information about the various types of modifications, and the reasons that clients accept and reject them, see Valid Realm Modifications Reference.
| Response | Description |
|---|---|
| OK | The client can accept the modifications, and continue running. |
| Require Restart | The current client process cannot accept the modifications, but restarting the client process would resolve the issue. |
| Rejected | The client program cannot accept the modifications. (Even restarting the client process would not suffice to resolve the issue.) |
| No Response | The realm server does not receive a response from the client program. (This symptom could indicate that the client has exited, or a network problem prevents communication.) |
Consolidation of Responses to Deployment Tests
A realm server consolidates the responses from all of its clients. The primary server consolidates the responses from all of its clients and all of its satellite servers.
The consolidated response is the least favorable response reported by any client or satellite server. For example, if 77 clients report OK, and one client reports Require Restart, then the consolidated response is Require Restart. If even one client were to report Rejected, then the consolidated response would be Rejected.
Satellite Servers Recursively Test Their Clients
Satellite realm servers broaden step 1 of the deploy transaction. The primary server not only tests the deployment against its own clients, it also tests the deployment against each of its satellite servers, which, in turn, test the modified realm definition against their clients and backup servers. Each of these clients determines whether it can accept the modifications and continue running. Each client reports its answer to the satellite server. Each satellite server combines the answers from its clients, and reports a single consolidated answer to the primary.
The primary consolidates the answers from its clients and satellites, using the same rules in Consolidation of Responses to Deployment Tests.
Unsuccessful Test
If the consolidated response is anything other than OK, then a dialog box again offers a set of options, as described previously.
Backup Prevents Satellite Update
A backup server is tightly coupled to its regular server, but a satellite is only loosely coupled to its primary server. As a result, a backup server B to a satellite S can prevent primary server P from updating S, but S cannot prevent P from updating itself and its other satellites. If B is unavailable when P attempts to update S, then S will remain out of sync with P until B again becomes available.