<lock>

Taking the <candidate> datastore lock is equivalent to starting a CLI exclusive session. A NETCONF session cannot take the <candidate> datastore lock if there are uncommitted configuration changes in the <candidate> datastore.

It is recommended that a NETCONF session should always take the <candidate> datastore lock before reading or writing configurations to ensure the <candidate> datastore is not changed by other model-driven sessions. Release the <candidate> datastore lock after all configurations are successfully read or committed.

When either the <running> datastore lock or the <candidate> datastore lock is taken by a NETCONF session:

no NETCONF session can take the <running> datastore lock
no NETCONF session can take the <candidate> datastore lock
no other NETCONF session can do an <edit-config> on the <running> datastore
no other NETCONF session can do an <edit-config> on the <candidate> datastore
no other NETCONF session can do a <commit> on the <candidate> datastore
no other NETCONF session can do a <discard-changes> on the <candidate> datastore
CLI becomes read-only
classic CLI rollback revert is blocked

A datastore lock is unlocked when disconnecting a NETCONF session (either from the CLI using the admin disconnect command, using Ctrl-c, or by performing a <kill-session> / <close-session> operation). Upon disconnecting a NETCONF session that had acquired a datastore lock, SR OS:

releases the lock
discards any ‟uncommitted” changes

Note: The behavior is different if the disconnected NETCONF session was using the global <candidate> datastore and had uncommitted configuration changes. In that case, SR OS keeps the ‟uncommitted” changes in the global <candidate> datastore.

Timeouts for locks are not supported. No specific admin or tools commands are provided to release the lock without disconnecting the session that holds it, but the session that holds the lock can be administratively disconnected through a CLI command to release the lock.

Using a CLI show command, the operator can determine whether the <running> datastore is locked, the <candidate> datastore is locked, or both are locked, and the session ID of the session that holds the lock.

From CLI, the operator can configure whether users that belong to a specific profile have permission to lock NETCONF sessions.

An active NETCONF session can be disconnected from the CLI using the session ID. The user can use the show command to find the NETCONF session ID, then use this session ID in the admin command to disconnect the NETCONF session.

To lock a BOF datastore, the ‟bof” <configuration-region> must be specified within the <lock> <target>. For example:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
          <lock>
                 <target>
                       <configuration-region>bof</configuration-region>
                       <candidate/>
                 </target>
          </lock>
</rpc>
]]>]]>

To lock an LI datastore, the ‟li” <configuration-region> must be specified within the <lock> <target>. For example:

<lock>
  <target>
    <configuration-region>li</configuration-region>
    <candidate/>
  </target>
</lock>

Alternatively, the <target> can be specified in the format of ‟configuration-region”-”datastore”. For example:

<lock>
  <target>
    <li-candidate/>
  </target>
</lock>

When both the <configuration-region> and the ‟configuration-region”-‟datastore” format are used, SR OS applies the last tag used in the XML request. For example:

<lock>
  <target> 
    <configuration-region>configure</configuration-region> 
    <li-candidate/>
  </target> 
</lock>

In the preceding example, the <lock> is used to lock the ‟li” <candidate> datastore.

The LI datastores have independent locks from the main configuration datastores.

See Table: Protocol operations and level of support in Nokia SR OS NETCONF servers for more details.