I went through the confd user guide and I still have some questions regarding the locking mechanism. I’ll try to explain what I understood and from that I’ll raise some questions.
When a transaction is in read state (section 7.5), one can fetch the operational data and the configuration data with the help of the maapi API. For operational data, there is no lock involved. For configuration data, a read-lock will be used on the database we reading from it (once the session is started). For instance, if one calls the function maapi_get_int32_elem on a given configuration leaf, that function will start a new session to the database, fetch the configuration data and then close the session.
When the user tries to commit some changes, confs will try to grab a read lock on the database (section 28.2.5) and also lock the transactions lock for that database (section 28.2.2). If it succeeds, from that moment no callbacks to any other transactions towards the same data store will be executed (section 7.7). Now I’m a bit confused about this statement.
If the statement is true: If no callbacks to any other transactions towards the same data store will be executed once the transaction lock is taken, why do we need to grab any lock on the database (assuming only the data provider has access to the datastore)? I also assume this would be true only for configuration data. It is still possible for a transaction (in read state then) to fetch operational data right?
If the statement is not true, to me it makes sense to have a read-lock, write-lock mechanism to a given datastore if for instance the transactional lock would not prohibit read accesses to this datastore as long as a write-lock is not taken (i.e as long as the state of this transaction being committed is located before the WRITE state). Actually, this goes with the fact that several read-locks can be taken on the same datastore. In that case, some transactions in read state could keep reading while a transaction (and only one, because of the transaction lock) is in its validate state. It also means that between two maapi_get_int32_elem calls (for instance) there could be a write transaction (a commit) occurring (from other manager). Once the read lock is released from this commit transaction (after validation), the transaction will try to grab a write lock on the database (section 28.2.5). If it succeeds before the second maapi_get_int32_elem gets the read lock then the write state (and all the following states) of the transaction being committed will occur first. This behavior raises another question, how can we code a netwonf get-config in a transnational way? Should take a global lock while reading all the data to make sure not commit will happen in between the readings?
If someone could shed some light on this that would be great!
Thanks in advance for your help,