Subscriber can register configuration change from RDB, and also Subscriber can modify CDB via APIs, if confd send the modification to subscriber again, it is not expected. could you give an guidance to break the loop between confd and subscriber, the setting from subscriber will be not send back from confd to subscriber?
Transactions are handled one by one in ConfD. First in first out style.
FIrst note that a transaction will not finish until the invoked subscribers have called cdb_sync_subscription_socket().
The only way a CDB subscriber can modify configuration data in CDB is through a northbound interface which in most cases would be through a MAAPI transaction. Only the CDB operational data store can be modified over the CDB API.
Note here that since a new transaction over MAAPI would wait for the transaction currently in progress to end, it is not recommended to start a transaction from a CDB subscriber since you would enter a deadlock.
You could start a new transaction over MAAPI from a separate thread, and that new transaction can invoke the CDB subscriber too. But only after the transaction currently in progress has finished, e.g. all the subscribers are done.
But note that changing the part of the configuration that the manager control over for example NETCONF, i.e. re-configuring yourself, is in most cases a bad idea, since now you are out of sync with the manager.
If do not want any more subscriber notifications for the current transaction you can from the subscriber reply with CDB_DONE_TRANSACTION. This means that CDB should not send any further notifications to any subscribers - including ourselves - related to the currently executing transaction.
See cdb_sync_subscription_socket() in the confd_lib_cdb man page.