How to unlock running datastore from callback function once it is locked?

[saraaibak]

Hi @michalvasko,

I am locking the running data store from the callback function for a particular leaf value so that no other session will not be able to make any modifications in the running data store. But I am not able to unlock from the same callback function even from the same session for a different value of that leaf.

edit-config --target running --config --defop replace ERROR type: application tag: operation-failed severity: error message: Module "ietf-interfaces" is DS-locked by session 33.

type:     application
tag:      operation-failed
severity: error
message:  User callback failed.

[michalvasko]

Please include the relevant code (the callback) and your netopeer2 version.

[saraaibak]

I am trying to lock the running datastore, if the lock flag is LOCKED and if it is UNLOCKED, unlock the datastore. Flag is set according to the configuration I am pushing.

if (lock_flag == LOCKED) {
    rc = sr_lock(session, NULL);
    if (rc != SR_ERR_OK) {
        printf("locking datastore is failed\n");
    }
} else if (lock_flag == UNLOCKED) {
    rc = sr_unlock(session, NULL);
    if (rc != SR_ERR_OK) {
        printf("Unlocking datastore is failed\n");
    }
}

I was able to lock the datastore, but not able to unlock and got the below error.

edit-config --target running --config --defop replace ERROR type: application tag: operation-failed severity: error message: Module "ietf-interfaces" is DS-locked by session 33.

type:     application
tag:      operation-failed
severity: error
message:  User callback failed.

Version I am using now is netopeer2 ([2.1.49]) libyang ([v2.1.30] libnetconf2 ([v2.1.28] and sysrepo ([v2.2.36]

[michalvasko]

So I am going to assume you lock the datastore before the callback is called and are then trying to unlock it in the callback. That is not going to work because the session that locked the datastore must be the same that unlocks it. If you really need to implement this, you can always pass the session to the callback in private_data but it seems like a bad design to me, it should ideally be one function that performs both locking and unlocking.