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/CONTROLLER-524 controller <p>Introduce an example which will showcase proper handling<br/> of failure of Data Broker commit, which failed because of OptimisticLockFailedException.</p> <p>Operating System: Windows<br/> Platform: PC</p> CONTROLLER-524

Introduce example which shows read/write/retry cycle with OptimisticLockFailedException

Improvement Resolved Done Tony Tkacik Tony Tkacik Fri, 30 May 2014 12:14:39 +0000 Thu, 3 Jul 2014 08:37:39 +0000 Thu, 3 Jul 2014 08:37:39 +0000 Helium mdsal Mon, 30 Jun 2014 00:00:00 +0000 0 4 <p><a href="https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Migration:Data_Broker#New_API_-_Write.2FCommit.2FRetry_Example" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Migration:Data_Broker#New_API_-_Write.2FCommit.2FRetry_Example</a></p> <p>The example isn't quite right. The logic needs to exhibit a read/modify/write loop and (in a synchronous pseudocode to make it easy to follow) it would look roughly like:</p> <p>while (true) {<br/> try </p> { Transaction t = newTransaction(); ChunkOData d = t.read(chunkodatapath); ChunkOData newChunk = modify(d, relevantEvent); t.write(chunkodatapath, newChunk); break; } <p> catch (ConcurrentModificationException) </p> { // nothing to do here } <p>}</p> <p>The read/modify part here is important for correctness, since if you get this exception if you just keep retrying your write you'll lose the data that was written by the other process or thread.</p> <p>Updated to:</p> <p>private void readWriteRetry() {<br/> ReadWriteTransaction writeTx = dataBroker.newReadWriteTransaction();</p> <p> Optional&lt;DataObject&gt; readed = writeTx.read(LogicalDatastoreType.OPERATIONAL,PATH).get();<br/> DataObject modified = modifyData(readed);<br/> writeTx.put(LogicalDatastoreType.OPERATIONAL, PATH, data);<br/> ListenableFuture&lt;RpcResult&lt;TransactionStatus&gt;&gt; future = writeTx.commit();</p> <p> Futures.addCallback(future, new FutureCallback&lt;RpcResult&lt;TransactionStatus&gt;&gt;() {</p> <p> @Override<br/> public void onSuccess(final RpcResult&lt;TransactionStatus&gt; result) </p> { // Commited successfully // Nothing to do } <p> @Override<br/> public void onFailure(final Throwable t) {<br/> // Transaction failed</p> <p> if(t instanceof OptimisticLockFailedException) </p> { LOG.error("Concurrent modification of data",e); readWriteRetry(); } <p> }<br/> });<br/> }</p> <p>This example is bit harder to read than your pseudocode, but illustrates read/write/retry using ListenableFutures<br/> to get transaction status.</p> <p>Looks much better, though this documentation really shouldn't be on this hidden page. I might change to:</p> <p>private void readWriteRetry(RelevantEvent event) </p> { // ... DataObject modified = modifyData(readed, event); // ... } <p>but this is not critical.</p> <p>By the way, do we recommend calling get() on the read operation future? Or are you supposed to write the double chain of async events?</p> <p>Is each module supposed to allocate its own executor or is there a global shared one to use?</p> <p>Futures.addCallback(Future,FutureCallback) for callback uses thread in which future completed (e.g. MD-SAL thread in this use cases). Futures.addCallback(Future,FutureCallback,Executor) uses executor of your choice.</p> <p>We do not have global shared executor.</p> Blocks CONTROLLER-522 Development External issue ID 1111 External issue URL Rank 0|i02kxj: