I’m occasionally seeing a problem when my code dies/restarts (and I think I saw it once on reboot). I have several different YANG modules. Lets say in Module #1, I define a list of objects. I’ve also typedef’ed a leafref type to point to these objects. Then I have module #2 which contains some leaves that are of that leafref type. Now during CLI configuration, the CLI enforces that the objects in module #1 must be created before the objects in Module #2 can reference them. What I am seeing occasionally is that when my subscription handlers for module #1 and module #2 get invoked to load the active configuration, under a few rare restarts/crashes I’m getting the configuration information for module #2 sent to me BEFORE module #1. Since my module #2 objects reference objects in module #1, badness ensues… Is this a bug in ConfD, or am I missing some sort of additional directive in my YANG modules to force the dependency? Again, most of the time it gives me module #1’s info first, then #2, just every now and then it doesn’t 
You can use priorities that you set when calling cdb_subscribe() to control the order of the subscriber notifications. It is up to the application to ensure that the priorities are set so that the Consistency (The ‘C’ in ACID) part of the (NETCONF) transaction is handled properly by the application.
• Transactions are all-at-once
• There is no internal order inside a transaction, it is a set of changes, not a sequence
• Implies that { create A, create B } and { create B, create A } are identical
• Implies that a system behaving differently with respect to the sequence is not transactional
From the confd_lib_cdb man page:
int cdb_subscribe(int sock, int priority, int nspace, int *spoint, const char *fmt, …);
The priority value is an integer. When CDB is changed, the change is performed inside a transaction. Either a commit operation from the CLI or a candidate-commit operation in NETCONF means that the running database is changed. These changes occur inside a ConfD transaction. CDB will handle the subscriptions in lock-step priority order. First all subscribers at the lowest priority are handled, once they all have replied and synchronized through calls to cdb_sync_subscription_socket() the next set - at the next priority level is handled by CDB. Priority numbers are global, i.e. if there are multiple client daemons notifications will still be delivered in priority order per all subscriptions, not per daemon.
Many thanks - I was following the linuxcfg example and mistakenly had all 3 of my modules subscribed at the NORMAL_PRIO level. Changed that up to order them explicitly rather than leaving it to chance. Thanks!