The Deploy Transaction
The deploy command initiates a transaction with the goal that all clients begin using the modified realm definition.
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 of all affiliated FTL servers (see
Affiliated Servers Test Their Clients).
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 FTL 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 its 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.
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 FTL server and its clients discard the modified realm definition, and continue as they were, using the realm definition of the previous successful 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 FTL 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.
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 FTL 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.) |
Affiliated Servers Test Their Clients
Affiliated FTL servers broaden step 1 of the deploy transaction. A server not only tests the deployment against its own clients, it also tests the deployment against each of its affiliated servers, which, in turn, test the modified realm definition against their clients.
Each of those clients determines whether it can accept the modifications and continue running. Each client reports its answer to its server. Each affiliated server combines the answers from its clients, and reports a single consolidated answer to the server that requested the recursive test.
The starting server consolidates the answers from its clients and satellites, using the same rules in Consolidation of Responses to Deployment Tests.
Consolidation of Responses to Deployment Tests
The starting server consolidates the responses from all of its clients and all of its affiliated servers.
The consolidated response is the least favorable response reported by any client or affiliated 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.