To start working with Sysrepo, a connection must be created first. Generally, one application (process) should create only one connection because there should be no reason to create several although it is allowed and Sysrepo will work correctly in both cases. Connection stores the main shared memory mapping and a corresponding libyang context among other things. This context can also be used in the application for learning about Sysrepo schemas or when working with data to save some resources but it can never be directly modified!

Then, an arbitrary number of sessions can be created. Most importantly, the threading model needs to be considered. Other than that there are no inherent restrictions in Sysrepo and because every session requires only little resources, having many of them should not cause any problems.

Every session always has a datastore selected that can be changed anytime. All API calls using this session will operate on this datastore. If a session works with running datastore and caching was enabled on the connection that was used to create this session, then data are not loaded every time from Sysrepo but rather duplicated from the cache. This can significantly improve performance or some operations and the cache is advised to always be used unless the application has strict requirements to keep its memory footprint small.

After every API call with session as a parameter, the error in the session is updated and if no error occured, it is cleared. In addition to standard logging, these errors can also be printed in any desired way to postpone the output, for example.

Also, every session has a unique ID among all Sysrepo sessions. This is useful when an operation fails because of another session (locked module, for instance). In addition, it is possible to learn what session initiated an event that is being processed in a subscription callback. In this case there is even an information about the NETCONF session (its ID) if the originator application stored it into the Sysrepo session.

Next, session user can be changed to an arbitrary one present on the system. This is useful for applications that serve only as an (remote) interface to Sysrepo. However, as this allows for a complete access control bypass, only root is allowed to do this.

Finally, when closing a connection, all sessions and subscriptions made on this connection are automatically freed as well.

Connection and Session API