org.opendaylight.genius.infra

Class RetryingManagedNewTransactionRunner

java.lang.Object

org.opendaylight.genius.infra.RetryingManagedNewTransactionRunner

All Implemented Interfaces:

ManagedNewTransactionRunner

@Beta
public class RetryingManagedNewTransactionRunner
extends Object

Implementation of ManagedNewTransactionRunner with automatic transparent retries.

Details about the threading model used by this class

This class runs the first attempt to call the delegated ManagedNewTransactionRunner, which typically is a ManagedNewTransactionRunnerImpl which safely invokes AsyncWriteTransaction.submit(), in the using application's thread (like a MoreExecutors.directExecutor() would, if this were an Executor, which it's not).

Any retry attempts required, if that submit() (eventually) fails with an OptimisticLockFailedException, are run in the calling thread of that eventual future completion by a MoreExecutors.directExecutor() implicit in the constructor which does not require you to specify an explicit Executor argument. Normally that will be an internal thread from the respective DataBroker implementation, not your application's thread anymore, because that meanwhile could well be off doing something else! Normally, that is not a problem, because retries "should" be relatively uncommon, and (re)issuing some DataBroker put() or delete() and re-submit() should be fast.

If this default is not suitable (e.g. for particularly slow try/retry code), then you can specify another Executor to be used for the retries by using the alternative constructor.

Author:

Michael Vorburger.ch

Constructor Summary

Constructors

Constructor and Description
RetryingManagedNewTransactionRunner(org.opendaylight.controller.md.sal.binding.api.DataBroker dataBroker) Constructor.
RetryingManagedNewTransactionRunner(org.opendaylight.controller.md.sal.binding.api.DataBroker dataBroker, Executor executor, int maxRetries) Constructor.
RetryingManagedNewTransactionRunner(org.opendaylight.controller.md.sal.binding.api.DataBroker dataBroker, int maxRetries) Constructor.

Method Summary

Modifier and Type	Method and Description
<E extends Exception,R> com.google.common.util.concurrent.ListenableFuture<R>	applyWithNewReadWriteTransactionAndSubmit(org.opendaylight.infrautils.utils.function.CheckedFunction<org.opendaylight.controller.md.sal.binding.api.ReadWriteTransaction,R,E> txRunner) Invokes a function with a NEW ReadWriteTransaction, and then submits that transaction and returns the Future from that submission, or cancels it if an exception was thrown and returns a failed future with that exception.
<E extends Exception> com.google.common.util.concurrent.ListenableFuture<Void>	callWithNewReadWriteTransactionAndSubmit(org.opendaylight.infrautils.utils.function.CheckedConsumer<org.opendaylight.controller.md.sal.binding.api.ReadWriteTransaction,E> txRunner) Invokes a consumer with a NEW ReadWriteTransaction, and then submits that transaction and returns the Future from that submission, or cancels it if an exception was thrown and returns a failed future with that exception.
<E extends Exception> com.google.common.util.concurrent.ListenableFuture<Void>	callWithNewWriteOnlyTransactionAndSubmit(org.opendaylight.infrautils.utils.function.CheckedConsumer<org.opendaylight.controller.md.sal.binding.api.WriteTransaction,E> txRunner) Invokes a consumer with a NEW WriteTransaction, and then submits that transaction and returns the Future from that submission, or cancels it if an exception was thrown and returns a failed future with that exception.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

RetryingManagedNewTransactionRunner

@Inject
public RetryingManagedNewTransactionRunner(org.opendaylight.controller.md.sal.binding.api.DataBroker dataBroker)

Constructor. Please see the class level documentation above for more details about the threading model used. This uses the default of 3 retries, which is typically suitable.

Parameters:

dataBroker - the DataBroker from which transactions are obtained

RetryingManagedNewTransactionRunner

public RetryingManagedNewTransactionRunner(org.opendaylight.controller.md.sal.binding.api.DataBroker dataBroker,
                                           int maxRetries)

Constructor. Please see the class level documentation above for more details about the threading model used.

Parameters:

dataBroker - the DataBroker from which transactions are obtained

maxRetries - the maximum number of retry attempts

RetryingManagedNewTransactionRunner

public RetryingManagedNewTransactionRunner(org.opendaylight.controller.md.sal.binding.api.DataBroker dataBroker,
                                           Executor executor,
                                           int maxRetries)

Constructor. Please see the class level documentation above for more details about the threading model used.

Parameters:

dataBroker - the DataBroker from which transactions are obtained

executor - the Executor to asynchronously run any retry attempts in

maxRetries - the maximum number of retry attempts

Method Detail

callWithNewWriteOnlyTransactionAndSubmit

public <E extends Exception> com.google.common.util.concurrent.ListenableFuture<Void> callWithNewWriteOnlyTransactionAndSubmit(org.opendaylight.infrautils.utils.function.CheckedConsumer<org.opendaylight.controller.md.sal.binding.api.WriteTransaction,E> txRunner)

Description copied from interface: ManagedNewTransactionRunner

Invokes a consumer with a NEW WriteTransaction, and then submits that transaction and returns the Future from that submission, or cancels it if an exception was thrown and returns a failed future with that exception. Thus when this method returns, that transaction is guaranteed to have been either submitted or cancelled, and will never "leak" and waste memory.

The consumer should not (cannot) itself use AsyncWriteTransaction.cancel(), AsyncWriteTransaction.commit() or AsyncWriteTransaction.submit() (it will throw an UnsupportedOperationException).

This is an asynchronous API, like DataBroker's own; when returning from this method, the operation of the Transaction may well still be ongoing in the background, or pending; calling code therefore must handle the returned future, e.g. by passing it onwards (return), or by itself adding callback listeners to it using Futures' methods, or by transforming it into a CompletionStage using ListenableFutures.toCompletionStage(ListenableFuture) and chaining on that, or at the very least simply by using ListenableFutures.addErrorLogging(ListenableFuture, org.slf4j.Logger, String) (but better NOT by using the blocking Future.get() on it).

Specified by:

callWithNewWriteOnlyTransactionAndSubmit in interface ManagedNewTransactionRunner

Parameters:

txRunner - the CheckedConsumer that needs a new write only transaction

Returns:

the ListenableFuture returned by AsyncWriteTransaction.submit(), or a failed future with an application specific exception (not from submit())

callWithNewReadWriteTransactionAndSubmit

public <E extends Exception> com.google.common.util.concurrent.ListenableFuture<Void> callWithNewReadWriteTransactionAndSubmit(org.opendaylight.infrautils.utils.function.CheckedConsumer<org.opendaylight.controller.md.sal.binding.api.ReadWriteTransaction,E> txRunner)

Description copied from interface: ManagedNewTransactionRunner

Invokes a consumer with a NEW ReadWriteTransaction, and then submits that transaction and returns the Future from that submission, or cancels it if an exception was thrown and returns a failed future with that exception. Thus when this method returns, that transaction is guaranteed to have been either submitted or cancelled, and will never "leak" and waste memory.

The consumer should not (cannot) itself use AsyncWriteTransaction.cancel(), AsyncWriteTransaction.commit() or AsyncWriteTransaction.submit() (it will throw an UnsupportedOperationException).

This is an asynchronous API, like DataBroker's own; when returning from this method, the operation of the Transaction may well still be ongoing in the background, or pending; calling code therefore must handle the returned future, e.g. by passing it onwards (return), or by itself adding callback listeners to it using Futures' methods, or by transforming it into a CompletionStage using ListenableFutures.toCompletionStage(ListenableFuture) and chaining on that, or at the very least simply by using ListenableFutures.addErrorLogging(ListenableFuture, org.slf4j.Logger, String) (but better NOT by using the blocking Future.get() on it).

Specified by:

callWithNewReadWriteTransactionAndSubmit in interface ManagedNewTransactionRunner

Parameters:

txRunner - the CheckedConsumer that needs a new read-write transaction

Returns:

the ListenableFuture returned by AsyncWriteTransaction.submit(), or a failed future with an application specific exception (not from submit())

applyWithNewReadWriteTransactionAndSubmit

public <E extends Exception,R> com.google.common.util.concurrent.ListenableFuture<R> applyWithNewReadWriteTransactionAndSubmit(org.opendaylight.infrautils.utils.function.CheckedFunction<org.opendaylight.controller.md.sal.binding.api.ReadWriteTransaction,R,E> txRunner)

Description copied from interface: ManagedNewTransactionRunner

Invokes a function with a NEW ReadWriteTransaction, and then submits that transaction and returns the Future from that submission, or cancels it if an exception was thrown and returns a failed future with that exception. Thus when this method returns, that transaction is guaranteed to have been either submitted or cancelled, and will never "leak" and waste memory.

The function must not itself use AsyncWriteTransaction.cancel(), or AsyncWriteTransaction.submit() (it will throw an UnsupportedOperationException).

This is an asynchronous API, like DataBroker's own; when returning from this method, the operation of the Transaction may well still be ongoing in the background, or pending; calling code therefore must handle the returned future, e.g. by passing it onwards (return), or by itself adding callback listeners to it using Futures' methods, or by transforming it into a CompletionStage using ListenableFutures.toCompletionStage(ListenableFuture) and chaining on that, or at the very least simply by using ListenableFutures.addErrorLogging(ListenableFuture, org.slf4j.Logger, String) (but better NOT by using the blocking Future.get() on it).

Specified by:

applyWithNewReadWriteTransactionAndSubmit in interface ManagedNewTransactionRunner

Parameters:

txRunner - the CheckedFunction that needs a new read-write transaction

Returns:

the ListenableFuture returned by AsyncWriteTransaction.submit(), or a failed future with an application specific exception (not from submit())