The Deploy Transaction

Deploying the workspace for the current realm definition involves several steps. The deploy command initiates a transaction so all clients begin using the modified realm definition.

Figure 41: Steps of the Deploy Transaction

  1. 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 response is OK (test succeeds) or an administrator forces the deployment to continue, the server proceeds to the next step. Otherwise the server rolls back the transaction.

  2. Write. The FTL server writes the modified workspace realm definition to its database.
  3. Activate. The FTL server instructs client application processes to begin using the modified realm definition.
  4. Archive. The FTL server copies the deployment package from the workspace directory to a deployment archive directory.
  5. 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 2Write. The FTL server writes the modified workspace realm definition to its database. . 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 Realm Modifications Reference.

Responses after Testing a Modified Realm Definition
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.

Successful Test

If the consolidated response is OK, then the deploy transaction proceeds to step 2.

Unsuccessful Test

If the consolidated response is anything other than OK, then a dialog box again offers a set of options, as described previously.