Operating System: All
Platform: All

Currently, netconf mountpoints provide DataBroker implementation that supports just one open write or read/write transaction at a time. Hence, when opening a second transaction, you can see this error.

The reason behind this single open transaction restriction is that every transaction locks the device. Lock is released upon transaction completion. Since the device is locked for the whole transaction life time, we can be sure that no one else can change device configuration.

Some possible solutions how to enable more than one open transaction:

1) Do not enable them. Netconf mountpoints do not provide DataBroker service but our own service that has this restriction documented properly.

2) Block on creating new transactions and wait until previous transaction completes.

3) Cache modifications done by multiple transactions, validate them on netconf southbound and validate them also against possible changes made concurrently on device independently from provided DataBroker. This is something we should consult with DataBroker API and most importantly with netconf RFC.

To clarify the problem scope and trade-offs. A mount point is backed by a single NETCONF session and all transactions execute on it.

Since netconf does not allow for multiple candidate stores for a particular session, we do not get any help from the RFC6241/device. Given that the candidate store may be shared across sessions, and there is no standardized way of discovering this, establishing multiple concurrent sessions may not provide a scalable solution (due to the need to lock) and may hit device connection limits.

Hence we have a three-dimensional solution space to search, with no single solution being the best fit for all devices because:

• having more than one session if there are no active applications is a waste both controller and device resources
• multiple sessions in case of shared candidate store is wasteful
• transactions have a logical order which must be preserved (i.e. DOMTransactionChain concrept)
• establishing a session is slow and may fail

Do VBD and GBP use TransactionChains?

As a quick fix for this problem we can use my second solution proposal, that is:

2) Block on creating new transactions and wait until previous transaction completes.

We can make this more general, by allowing to specify a timeout for blocking on creating a new transaction. After timeout, opening a new transaction will fail with a specific exception, rather than just general TimeoutException or IllegalStateExpcetion. This timeout can be specified in netconf node configuration. Also, we should document this DataBroker implementation properly, what are the restrictions and limitations to it.

Since this is a quick fix and it does not really allow for multiple transactions open at a time, I also opened a milestone ODLPARENT-77 where we can continue to track this multiple transactions open issue (and also other related issues).

Sorry the milestone bug is NETCONF-370 not ODLPARENT-77

Moving correctly to next service release, Carbon Sr1, the closest release, for bugfix.

We should track this under NETCONF-370 (which is about mountpoint concurrent transactions in general) , closing this as a duplicate of that milestone.