To lock the candidate configuration, a client application emits the <lock-configuration/> tag within an <rpc> tag element:
<rpc>
<lock-configuration/>
</rpc>
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 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.
When the JUNOScript 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 JUNOScript 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:
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 JUNOScript 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 JUNOScript session ends for any reason before the changes are committed, the changes are automatically discarded. The candidate and committed configurations remain unchanged.