ezghodh If you're not actively working on this please unassign yourself so someone else can work on this.

Review added doesn't use DS constraint txn at all the places. It is difficult to add where same transaction is used for both config and oper. Similarly it is difficult to use for places where blocking calls are used.

Could you give an example where blocking calls make it difficult to use?

For eg: deleteElanInterfaceForwardingTablesList in ElanForwardingEntriesHandler.java is called from 2 places( one from deleteElanInterfaceForwardingEntries and updateElanInterfaceForwardingTablesList from same file).  It is easy to move to DS constraint tx in deleteElanInterfaceForwardingEntries  but difficult at updateElanInterfaceForwardingTablesList. This is because updateElanInterfaceForwardingTablesList is called from update method of ElanInterfaceManager.java which doesn't use txRunner(due to blocked call).

This resulted in not using DS constraint txn in both deleteElanInterfaceForwardingEntries and updateElanInterfaceForwardingTablesList.

Please let me know if there is any better way to use it.

The better way is to use an existing transaction in `ElanInterfaceManager::update`, without blocking. (Blocking shouldn’t be necessary if all the dependencies are in the same transaction.)

Do we need to take up removal of blocking calls in the current activity? It could have impact in the functionalities. There are 5 usage of ElanUtils::waitForTransactionToComplete.(blocking calls)
Some are related to data dependencies and there are already work going on txn chaining those areas. Other usages seems to be added for race conditions.

Please let me know your views.

As always, if it makes the patch unwieldy, it’s fine to split the patch up. Especially if work is being done in other patches to address these issues, it makes sense to push an initial patch converting what can easily be converted, and then follow up with another patch once the other patches have been merged. (But this bug shouldn’t be marked as “done” until everything is done.)

Note that converting code to use a single transaction which is passed down avoids a number of these issues: changes made in a transaction are visible inside that transaction, which means some waits can be removed. There should also be fewer race conditions as a result of this work.

with https://git.opendaylight.org/gerrit/#/c/74026/ not yet, let's re-use this issue, for clear status.