[Contents] [Prev] [Next] [Index] [Report an Error]

Locking the Candidate Configuration

To lock the candidate configuration, a client application emits the <lock> and <target> tag elements and the <candidate/> tag in the <rpc> tag element:



<rpc>
    
<lock> 

        
<target> 

            
<candidate/> 

        
</target> 

    
</lock> 

</rpc>
]]>]]>

Emitting these tag elements 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 before making changes is recommended, particularly on routing platforms 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.

The NETCONF server confirms that it has locked the candidate by returning the <ok/> tag in the <rpc-reply> tag element:



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

If the NETCONF server cannot lock the configuration, the <rpc-reply> tag element instead encloses an <rpc-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 NETCONF session identifier of the user or application. If the client application has the necessary JUNOS access privilege, it can terminate the session that holds the lock. For more information, see Terminating Another NETCONF Session.
The candidate configuration already includes changes that have not yet been committed. To commit the changes, see Committing a Configuration. To discard uncommitted changes, see Rolling Back a 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. The lock persists until either the NETCONF session ends or the client application unlocks the configuration by emitting the <unlock> tag element, as described in Unlocking the Candidate Configuration.

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

[Contents] [Prev] [Next] [Index] [Report an Error]