https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-775 mdsal <p>The ability to access multiple datastores in a single transaction is something we supported on a best-effort basis, but there is no concept of cross-datastore atomicity.</p> <p>As such, no downstreams should be using this facility – remove this ability, forcing users to have a separate transaction for each datastore.</p> MDSAL-775

Do not allow cross-datastore transactions

Task Medium Resolved Done Ruslan Kashapov Robert Varga pt Mon, 10 Oct 2022 08:23:28 +0000 Tue, 8 Nov 2022 12:23:28 +0000 Mon, 7 Nov 2022 16:08:48 +0000 11.0.0 DOM runtime 0 2 <p>there is a limitation to what can be done as solution for current task<br/> due to the way the datastore being addressed using current API.</p> <p>in order to operate with data from a specific datastore the composite transaction <br/> object should be created first, then only datastore will be addressed as an<br/> argument of read/write operation like below</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">final</span> WriteTransaction tx = dataBroker.newWriteOnlyTransaction(); tx.merge(LogicalDatastoreType.CONFIGURATION, DATA_IID, data); </pre> </div></div> <p>it means backing transactions for all the datastores require to be instantiated<br/> before the actual datastore is mentioned.</p> <p>the composite transaction is being created by dataBroker from the set of datastores<br/> provided on databroker initialization. it means in order to have single backing transaction<br/> within composite one the dataBroker have to be always initialized with single datastore.</p> <p>necessity to have separate databroker instance for each datastore isn't suitable<br/> with current usage of databroker, it means no backward compatibility.</p> <p>#1</p> <p>the compromise solution could be logical restriction within transaction itself by controlling<br/> the datastore type to match the first requested one like shown below</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">final</span> WriteTransaction tx = dataBroker.newWriteOnlyTransaction(); tx.merge(LogicalDatastoreType.CONFIGURATION, DATA_IID, data); <span class="code-comment">// first operation, datastore type registered  </span>tx.merge(LogicalDatastoreType.CONFIGURATION, DATA_IID2, data2); <span class="code-comment">// datastore matches, passed ok </span>tx.merge(LogicalDatastoreType.OPERATIONAL, DATA_IID, data); <span class="code-comment">// datastore mismatches, exception thrown </span></pre> </div></div> <p>while this approach solves 'single datastore per transaction' while API remain as is,<br/> in fact the update will bring no benefits: no optimization (same backing transactions require <br/> instantiation anyway), no inner logic modified, just introducing annoying extra restriction <br/> causing inobvious backward incompatibility (for those addressing different datastores in same <br/> transaction new exception will be introduced).</p> <p>#2</p> <p>imo more reasonable approach would be introducing new api using single store transactions,<br/> with gradual migration (deprecate old api first, remove deprecated api and classes later).<br/> so the transaction will be initially tied to single datastore, so it became unnecessary <br/> as an operation argument, the code will look like below</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-comment">// <span class="code-keyword">new</span> transaction interfaces, <span class="code-keyword">new</span> databroker methods to build single datastore transactions </span><span class="code-keyword">final</span> DatastoreWriteTransaction tx = dataBroker.newWriteOnlyTransaction(LogicalDatastoreType.CONFIGURATION); tx.merge(DATA_IID, data); <span class="code-comment">// datastore is known already</span></pre> </div></div> <p>while this approach seems more future-proof, it also requires more effort and a new set of <br/> transaction related interfaces to be introduced</p> <p>#3<br/> another compromise (with keeping existing API) could be limiting number of  backed transactions if<br/> is to add databroker method to build composite transaction with single backing transaction </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-comment">// old transaction interfaces, <span class="code-keyword">new</span> databroker methods </span><span class="code-keyword">final</span> WriteTransaction tx = dataBroker.newWriteOnlyTransaction(LogicalDatastoreType.CONFIGURATION); tx.merge(LogicalDatastoreType.CONFIGURATION, DATA_IID, data); <span class="code-comment">// ok </span>tx.merge(LogicalDatastoreType.OPERATIONAL, DATA_IID, data); <span class="code-comment">// IllegalStateException, current behavior</span></pre> </div></div> <p>the approach need to be clarified</p> <p> </p> <p>Approach 1, definitely, as we need to catch violations first and allow <b>implementations</b> to rely on the fact this is not allowed.</p> <p>We have datastore-bound versions of the WriteTransaction et al. prepared, but rolling those out is going to be a point.</p> Issue split CONTROLLER-2055 Development Rank 0|i0433b: