Locking and Unlocking the Candidate Configuration or Creating a Private Copy

When a client application is requesting or changing configuration information, it can use one of three methods to access the configuration:

Lock the candidate configuration, which prevents other users or applications from changing the configuration until the application releases the lock (equivalent to the CLI configure exclusive command).
Create a private copy of the candidate configuration, which enables the application to view or change configuration data without affecting the candidate or active configuration until the private copy is committed (equivalent to the CLI configure private command).
Change the candidate configuration without locking it. We do not recommend this method, because of the potential for conflicts with changes made by other applications or users that are editing the configuration at the same time.

If an application is simply requesting configuration information and not changing it, locking the configuration or creating a private copy is not required. However, it is appropriate to lock the configuration if it is important that the information being returned not change during the session. The information from a private copy is guaranteed not to change, but can diverge from the candidate configuration if other users or applications are changing the candidate.

The restrictions on, and interactions between, operations on the locked regular candidate configuration and a private copy are the same as for the CLI configure exclusive and configure private commands. For more information, see Committing a Private Copy of the Configuration and the Junos CLI User Guide.

For more information about locking and unlocking the candidate configuration or creating a private copy, see the following sections:

Locking the Candidate Configuration

To lock the candidate configuration, a client application emits the <lock-configuration/> tag within an <rpc> tag element:

Emitting this tag prevents other users or applications from changing the candidate configuration until the lock is released (equivalent to the CLI configure exclusive command). Locking the configuration is recommended, particularly on devices where multiple users are authorized to change the configuration. A commit operation applies to all changes in the candidate configuration, not just those made by the user or application that requests the commit. Allowing multiple users or applications to make changes simultaneously can lead to unexpected results.

When the Junos XML protocol server locks the configuration, it returns an opening <rpc-reply> and closing </rpc-reply> tag with nothing between them:

<rpc-reply xmlns:junos="URL"></rpc-reply>

If the Junos XML protocol server cannot lock the configuration, the <rpc-reply> tag element instead encloses an <xnm:error> tag element explaining the reason for the failure. Reasons for the failure can include the following:

Another user or application has already locked the candidate configuration. The error message reports the login identity of the user or application.
The candidate configuration already includes changes that have not yet been committed. To commit the changes, see Committing a Configuration. To roll back to a previous version of the configuration (and lose the uncommitted changes), see Rolling Back to a Previous or Rescue Configuration.

Only one application can hold the lock on the candidate configuration at a time. Other users and applications can read the candidate configuration while it is locked, or can change their private copies. The lock persists until either the Junos XML protocol session ends or the client application unlocks the configuration by emitting the <unlock-configuration/> tag, as described in Unlocking the Candidate Configuration.

If the candidate configuration is not committed before the client application unlocks it, or if the Junos XML protocol session ends for any reason before the changes are committed, the changes are automatically discarded. The candidate and committed configurations remain unchanged.

Unlocking the Candidate Configuration

As long as a client application holds a lock on the candidate configuration, other applications and users cannot change the candidate. To unlock the candidate configuration, the client application includes the <unlock-configuration/> tag in an <rpc> tag element:

To confirm that it has successfully unlocked the configuration, the Junos XML protocol server returns an opening <rpc-reply> and closing </rpc-reply> tag with nothing between them:

<rpc-reply xmlns:junos="URL"></rpc-reply>

If the Junos XML protocol server cannot unlock the configuration, the <rpc-reply> tag element instead encloses an <xnm:error> tag element explaining the reason for the failure.

Creating a Private Copy of the Configuration

To create a private copy of the candidate configuration, a client application emits the <private/> tag enclosed in <rpc> and <open-configuration> tag elements:

The client application can then perform the same operations on the private copy as on the regular candidate configuration, as described in Changing Configuration Information.

After making changes to the private copy, the client application can commit the changes to the active configuration on the device running Junos OS by emitting the <commit-configuration> tag element, as for the regular candidate configuration. However, there are some restrictions on the commit operation for a private copy. For more information, see Committing a Private Copy of the Configuration.

To discard the private copy without committing it, a client application emits the <close-configuration/> tag enclosed in an <rpc> tag element:

Any changes to the private copy are lost. Changes to the private copy are also lost if the Junos XML protocol session ends for any reason before the changes are committed. It is not possible to save changes to a private copy other than by emitting the <commit-configuration> tag element.

The following example shows how to create a private copy of the configuration. The Junos XML protocol server includes a reminder in its confirmation response that changes are discarded from a private copy if they are not committed before the session ends.