The CertificateGroups and TrustLists used by a Server may be updated as part of a transaction where multiple Methods are invoked, however, no changes will have any effect until ApplyChanges is called (see 7.10.7). These transactions are created automatically and the Server returns applyChangesRequired =TRUE in a Method response to tell the Client that a transaction is active. Servers that do not support transactions return applyChangesRequired =FALSE and apply any changes before returning a Method response.

If a Method called within a transaction fails (e.g. a parameter was invalid) the transaction state shall not change and all previous changes are applied when ApplyChanges is called.

Once a transaction is created, a Server shall queue the changes in the order that they were requested within the current Session. When ApplyChanges is called the Server verifies that all the changes are consistent and can be applied without errors. If any errors are found then all changes are discarded. If no errors are found, the Server applies all changes.

If errors occur, they are reported in the TransactionDiagnostics Object (see 7.10.12).

The life cycle of a transaction is shown in Figure 22.

Figure 22 – The Transaction Lifecycle when using PushManagement

Servers that implement the transaction model shall support the CancelChanges Method and always set applyChangesRequired to TRUE.

Servers that support the transaction model are expected to support exactly one active transaction. Once a transaction has started in Session all other Sessions will not be able to modify TrustLists or Certificates. Transactions are automatically cancelled when the Session that created it is closed or when the CancelChanges Method is called.

If the transaction model is not supported and applyChangesRequired is TRUE then the behaviour of the Server for multiple changes is undefined.

If applyChangesRequired is FALSE then any changes are applied before the Method response is sent.