</dependency>
</dependencies>
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-checkstyle-plugin</artifactId>
+ <configuration>
+ <propertyExpansion>checkstyle.violationSeverity=error</propertyExpansion>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
+
<scm>
<connection>scm:git:http://git.opendaylight.org/gerrit/mdsal.git</connection>
<developerConnection>scm:git:ssh://git.opendaylight.org:29418/mdsal.git</developerConnection>
*/
package org.opendaylight.mdsal.common.api;
-import org.opendaylight.yangtools.concepts.ListenerRegistration;
import org.opendaylight.yangtools.concepts.Path;
+
/**
- *
* Base interface that provides access to a conceptual data tree store and also provides the ability
* to subscribe for changes to data under a given branch of the tree.
*
public interface AsyncDataBroker<P extends Path<P>, D> extends
AsyncDataTransactionFactory<P, D> {
- /**
- * {@inheritDoc}
- */
+
@Override
AsyncReadTransaction<P, D> newReadOnlyTransaction();
- /**
- * {@inheritDoc}
- */
@Override
AsyncWriteTransaction<P, D> newWriteOnlyTransaction();
}
import org.opendaylight.yangtools.concepts.Path;
+
/**
* A factory which allocates new transactions to operate on the data tree.
*
* example, implementations may optimize the transaction for reading if they know ahead of time that
* you only need to read data - such as not keeping additional meta-data, which may be required for
* write transactions.
+ *
* <p>
* <b>Implementation Note:</b> This interface is not intended to be implemented by users of MD-SAL,
* but only to be consumed by them.
/**
* Allocates a new read-only transaction which provides an immutable snapshot of
* the data tree.
+ *
*<p>
* The view of data tree is an immutable snapshot of current data tree state when
* transaction was allocated.
* Since this transaction does not provide a view of the data it SHOULD BE used only by callers
* which are exclusive writers (exporters of data) to the subtree they modify. This prevents
* optimistic lock failures as described in {@link AsyncWriteTransaction#submit()}.
+ *
* <p>
* Exclusivity of writers to particular subtree SHOULD BE enforced by external locking
* mechanism.
import org.opendaylight.yangtools.concepts.Path;
+
/**
- *
* Marker interface for stateful read view of the data tree.
*
* <p>
* <pre>
* txRead = broker.newReadOnlyTransaction(); // read Transaction is snapshot of data
* txWrite = broker.newReadWriteTransactoin(); // concurrent write transaction
- *
* txRead.read(OPERATIONAL, PATH).get(); // will return Optional containing A
* txWrite = broker.put(OPERATIONAL, PATH, B); // writes B to PATH
- *
* txRead.read(OPERATIONAL, PATH).get(); // still returns Optional containing A
- *
* txWrite.submit().get(); // data tree is updated, PATH contains B
* txRead.read(OPERATIONAL, PATH).get(); // still returns Optional containing A
- *
* txAfterCommit = broker.newReadOnlyTransaction(); // read Transaction is snapshot of new state
* txAfterCommit.read(OPERATIONAL, PATH).get(); // returns Optional containing B;
* </pre>
* after other asynchronous action. Use of blocking call
* {@link com.google.common.util.concurrent.ListenableFuture#get()} is discouraged for most uses and
* you should use
- * {@link com.google.common.util.concurrent.Futures#addCallback(com.google.common.util.concurrent.ListenableFuture, com.google.common.util.concurrent.FutureCallback)}
+ * {@link com.google.common.util.concurrent.Futures#addCallback(com.google.common.util.concurrent.
+ * ListenableFuture, com.google.common.util.concurrent.FutureCallback)}
* or other functions from {@link com.google.common.util.concurrent.Futures} to register more
* specific listeners.
*
*
*/
@Override
- public void close();
+ void close();
}
/**
- *
* A common parent for all transactions which operate on a conceptual data tree.
- *
* See derived transaction types for more concrete behavior:
* <ul>
* <li>{@link AsyncReadTransaction} - Read capabilities, user is able to read data from data tree</li>
* Initial state of write transaction is a stable snapshot of the current data tree.
* The state is captured when the transaction is created and its state and underlying
* data tree are not affected by other concurrently running transactions.
+ *
* <p>
* Write transactions are isolated from other concurrent write transactions. All
* writes are local to the transaction and represent only a proposal of state
* change for the data tree and it is not visible to any other concurrently running
* transaction.
+ *
* <p>
* Applications make changes to the local data tree in the transaction by via the
* <b>put</b>, <b>merge</b>, and <b>delete</b> operations.
* Stores a piece of data at a specified path. This acts as an add / replace
* operation, which is to say that whole subtree will be replaced by the
* specified data.
+ *
* <p>
* Performing the following put operations:
*
* 1) container { list [ a ] }
* 2) container { list [ b ] }
* </pre>
- *
* will result in the following data being present:
*
* <pre>
* Merges a piece of data with the existing data at a specified path. Any pre-existing data
* which is not explicitly overwritten will be preserved. This means that if you store a container,
* its child lists will be merged.
+ *
* <p>
* Performing the following merge operations:
*
* 1) container { list [ a ] }
* 2) container { list [ b ] }
* </pre>
- *
* will result in the following data being present:
*
* <pre>
* container { list [ a, b ] }
* </pre>
- *
* This also means that storing the container will preserve any
* augmentations which have been attached to it.
*
* <h2>Delete operation</h2>
* Removes a piece of data from a specified path.
+ *
* <p>
* After applying changes to the local data tree, applications publish the changes proposed in the
* transaction by calling {@link #submit} on the transaction. This seals the transaction
* (preventing any further writes using this transaction) and submits it to be
* processed and applied to global conceptual data tree.
+ *
* <p>
* The transaction commit may fail due to a concurrent transaction modifying and committing data in
* an incompatible way. See {@link #submit} for more concrete commit failure examples.
+ *
* <p>
* <b>Implementation Note:</b> This interface is not intended to be implemented
* by users of MD-SAL, but only to be consumed by them.
public interface AsyncWriteTransaction<P extends Path<P>, D> extends AsyncTransaction<P, D> {
/**
* Cancels the transaction.
- *
* Transactions can only be cancelled if it was not yet submited.
- *
* Invoking cancel() on failed or already canceled will have no effect, and transaction is
* considered cancelled.
- *
* Invoking cancel() on finished transaction (future returned by {@link #submit()} already
* successfully completed) will always fail (return false).
*
/**
* Submits this transaction to be asynchronously applied to update the logical data tree. The
* returned CheckedFuture conveys the result of applying the data changes.
+ *
* <p>
* <b>Note:</b> It is strongly recommended to process the CheckedFuture result in an
* asynchronous manner rather than using the blocking get() method. See example usage below.
+ *
* <p>
* This call logically seals the transaction, which prevents the client from further changing
* data tree using this transaction. Any subsequent calls to
* <code>put(LogicalDatastoreType, Path, Object)</code>,
* <code>merge(LogicalDatastoreType, Path, Object)</code>,
* <code>delete(LogicalDatastoreType, Path)</code> will fail with {@link IllegalStateException}.
- *
* The transaction is marked as submitted and enqueued into the data store back-end for
* processing.
*
* <p>
* Whether or not the commit is successful is determined by versioning of the data tree and
* validation of registered commit participants if the transaction changes the data tree.
+ *
* <p>
- * The effects of a successful commit of data depends on listeners
+ * The effects of a successful commit of data depends on listeners
* and commit participants that are registered with the data
* broker.
* <h3>Example usage:</h3>
* <pre>
* private void doWrite( final int tries ) {
* WriteTransaction writeTx = dataBroker.newWriteOnlyTransaction();
- *
* MyDataObject data = ...;
* InstanceIdentifier<MyDataObject> path = ...;
* writeTx.put( LogicalDatastoreType.OPERATIONAL, path, data );
- *
* Futures.addCallback( writeTx.submit(), new FutureCallback<Void>() {
* public void onSuccess( Void result ) {
* // succeeded
* }
- *
* public void onFailure( Throwable t ) {
* if( t instanceof OptimisticLockFailedException ) {
* if( ( tries - 1 ) > 0 ) {
* </pre>
*
* <h2>Failure scenarios</h2>
+ *
* <p>
* Transaction may fail because of multiple reasons, such as
* <ul>
* </ul>
*
* <h3>Change compatibility</h3>
- *
* There are several sets of changes which could be considered incompatible between two
* transactions which are derived from same initial state. Rules for conflict detection applies
* recursively for each subtree level.
*
* <h4>Change compatibility of leafs, leaf-list items</h4>
- *
* Following table shows state changes and failures between two concurrent transactions, which
* are based on same initial state, Tx 1 completes successfully before Tx 2 is submitted.
*
* </table>
*
* <h4>Change compatibility of subtrees</h4>
- *
* Following table shows state changes and failures between two concurrent transactions, which
* are based on same initial state, Tx 1 completes successfully before Tx 2 is submitted.
*
* <h3>Examples of failure scenarios</h3>
*
* <h4>Conflict of two transactions</h4>
- *
* This example illustrates two concurrent transactions, which derived from same initial state
* of data tree and proposes conflicting modifications.
*
* <pre>
* txA = broker.newWriteTransaction(); // allocates new transaction, data tree is empty
* txB = broker.newWriteTransaction(); // allocates new transaction, data tree is empty
- *
* txA.put(CONFIGURATION, PATH, A); // writes to PATH value A
* txB.put(CONFIGURATION, PATH, B) // writes to PATH value B
- *
* ListenableFuture futureA = txA.submit(); // transaction A is sealed and submitted
* ListenebleFuture futureB = txB.submit(); // transaction B is sealed and submitted
* </pre>
- *
* Commit of transaction A will be processed asynchronously and data tree will be updated to
* contain value <code>A</code> for <code>PATH</code>. Returned {@link ListenableFuture} will
* successfully complete once state is applied to data tree.
- *
* Commit of Transaction B will fail, because previous transaction also modified path in a
* concurrent way. The state introduced by transaction B will not be applied. Returned
* {@link ListenableFuture} object will fail with {@link OptimisticLockFailedException}
*/
package org.opendaylight.mdsal.common.api;
+import com.google.common.base.Preconditions;
import org.opendaylight.yangtools.concepts.Path;
import org.opendaylight.yangtools.yang.common.RpcError.ErrorType;
import org.opendaylight.yangtools.yang.common.RpcResultBuilder;
-import com.google.common.base.Preconditions;
/**
- *
* Failure of asynchronous transaction commit caused by invalid data.
- *
* This exception is raised and returned when transaction commit
* failed, because other data submitted via transactions
- *
* Clients usually are not able recover from this error condition by
* retrieving same transaction, since data introduced by this transaction
* are invalid.
private static final long serialVersionUID = 1L;
- private Path<?> path;
+ private final Path<?> path;
- private Class<? extends Path<?>> pathType;
+ private final Class<? extends Path<?>> pathType;
public <P extends Path<P>> DataValidationFailedException(final Class<P> pathType,final P path,
final String message, final Throwable cause) {
/**
* Logical atastore representing operational state of the system
* and it's components
- *
* This datastore is used to describe operational state of
* the system and it's operation related data.
*
/**
* Logical Datastore representing configuration state of the system
* and it's components.
- *
* This datastore is used to describe intended state of
* the system and intended operation mode.
*
package org.opendaylight.mdsal.common.api;
-import org.opendaylight.yangtools.yang.common.RpcResultBuilder;
import org.opendaylight.yangtools.yang.common.RpcError.ErrorType;
+import org.opendaylight.yangtools.yang.common.RpcResultBuilder;
+
/**
-*
* Failure of asynchronous transaction commit caused by failure
* of optimistic locking.
-*
* This exception is raised and returned when transaction commit
* failed, because other transaction finished successfully
* and modified same data as failed transaction.
-*
* Clients may recover from this error condition by
* retrieving current state and submitting new updated
* transaction.
import javax.annotation.Nonnull;
/**
- *
* User implementation of steps following can-commit in three phase protocol.
- *
* If no additional visibility into transaction and data being aborted or committed is needed, use
* {@link #NOOP} implementation.
*
/**
* No-op implementation of abort, pre-commit and commit steps.
- *
* This implementation should be used if user logic does only validation of data and does not
* need to perform any actions associated with pre-commit, commit or abort.
*/
/**
* Initiates a pre-commit of associated request
- *
* Implementation MUST NOT do any blocking calls during this callback, all pre-commit
* preparation SHOULD happen asynchronously and MUST result in completing returned future
* object.
import com.google.common.util.concurrent.ListenableFuture;
/**
- *
* User implementation of steps following pre-commit from Three-Phase Protocol.
*
*/
/**
* No-op implementation of {@link #abort()} and {@link #commit()} method, which always success
* calls.
- *
* This implementation is intended for users which may not need to implement commit and abort
* method.
*
ListenableFuture<? extends PostPreCommitStep> NOOP_FUTURE = Futures.immediateFuture(NOOP);
/**
- *
* Commits cohort transaction.
- *
* This callback is invoked by three-phase commit coordinator if associated data transaction
* finished pre-commit phase and will be commited.
- *
* Implementation should make state, which were derived by implementation from associated data
* visible.
*
public static final ExceptionMapper<ReadFailedException> MAPPER =
new ExceptionMapper<ReadFailedException>("read", ReadFailedException.class) {
- @Override
- protected ReadFailedException newWithCause(String message, Throwable cause) {
- return new ReadFailedException(message, cause);
- }
+ @Override
+ protected ReadFailedException newWithCause(String message, Throwable cause) {
+ return new ReadFailedException(message, cause);
+ }
};
public ReadFailedException(String message, RpcError... errors) {
/**
* Common interface for implementing three-phase commit steps.
- *
* Actual steps to be implemented are: {@link PostCanCommitStep} and {@link PostPreCommitStep} which
* allows to customize pre-commit, commit and abort actions.
*
/**
* Invoked on transaction aborted.
- *
* This callback is invoked by three-phase commit coordinator if associated data transaction
* will not be commited and is being aborted.
- *
* Implementation MUST rollback any changes, which were introduced by implementation based on
* supplied data.
*
* sequence and each transaction should see the effects of previous committed transactions
* as they occurred. A chain makes no guarantees of atomicity across the chained transactions -
* the transactions are committed as soon as possible in the order that they were submitted.
- *
* This behaviour is different from the default AsyncDataBroker, where a
* transaction is always created from the current global state, not taking into
* account any transactions previously committed by the calling thread. Due to
* AsyncReadTransaction t2 = broker.newReadOnlyTransaction();
* Optional<?> maybeData = t2.read(id).get();
* </code></pre>
- *
* it may happen, that it sees maybeData.isPresent() == false, simply because
* t1 has not completed the processes of being applied and t2 is actually
* allocated from the previous state. This is obviously bad for users who create
* incremental state in the datastore and actually read what they write in
* subsequent transactions.
- *
* Using a TransactionChain instead of a broker solves this particular problem,
* and leads to expected behavior: t2 will always see the data written in t1
* present.
* The previous write transaction has to be either SUBMITTED
* ({@link AsyncWriteTransaction#submit submit} was invoked) or CANCELLED
* ({@link #close close} was invoked).
+ *
* <p>
* The returned read-only transaction presents an isolated view of the data if the previous
* write transaction was successful - in other words, this read-only transaction will see the
* if the chain has been closed.
*/
@Override
-
public AsyncReadTransaction<P, D> newReadOnlyTransaction();
+ AsyncReadTransaction<P, D> newReadOnlyTransaction();
/**
* Create a new write-only transaction which will continue the chain.
* <p>
* The previous write transaction has to be either SUBMITTED
* ({@link AsyncWriteTransaction#submit submit} was invoked) or CANCELLED
- * ({@link #close close} was invoked).
+ * ({@link #close close} was invoked)
+ *
* <p>
* The returned write-only transaction presents an isolated view of the data if the previous
* write transaction was successful - in other words, this write-only transaction will see the
* state changes made by the previous write transaction in the chain. However, state which
* was introduced by other transactions outside this transaction chain after creation of
- * the previous transaction is not visible.
+ * the previous transaction is not visible
+ *
* <p>
* Committing this write-only transaction using {@link AsyncWriteTransaction#submit submit}
* will submit the state changes in this transaction to be visible to any subsequent
* if the chain has been closed.
*/
@Override
-
public AsyncWriteTransaction<P, D> newWriteOnlyTransaction();
+ AsyncWriteTransaction<P, D> newWriteOnlyTransaction();
@Override
void close();
package org.opendaylight.mdsal.common.api;
import com.google.common.base.Supplier;
+
import org.opendaylight.yangtools.yang.common.RpcError;
import org.opendaylight.yangtools.yang.common.RpcError.ErrorType;
import org.opendaylight.yangtools.yang.common.RpcResultBuilder;
+
+
+
/**
* A type of TransactionCommitFailedException that indicates a situation that would result in a
* threading deadlock. This can occur if a caller that submits a write transaction tries to perform
public class TransactionCommitDeadlockException extends TransactionCommitFailedException {
private static final long serialVersionUID = 1L;
private static final String DEADLOCK_MESSAGE =
- "An attempt to block on a ListenableFuture via a get method from a write " +
- "transaction submit was detected that would result in deadlock. The commit " +
- "result must be obtained asynchronously, e.g. via Futures#addCallback, to avoid deadlock.";
- private static final RpcError DEADLOCK_RPCERROR = RpcResultBuilder.newError(ErrorType.APPLICATION, "lock-denied", DEADLOCK_MESSAGE);
+ "An attempt to block on a ListenableFuture via a get method from a write "
+ +
+ "transaction submit was detected that would result in deadlock. The commit "
+ +
+ "result must be obtained asynchronously, e.g. via Futures#addCallback, to avoid deadlock.";
+ private static final RpcError DEADLOCK_RPCERROR =
+ RpcResultBuilder.newError(ErrorType.APPLICATION, "lock-denied", DEADLOCK_MESSAGE);
public static final Supplier<Exception> DEADLOCK_EXCEPTION_SUPPLIER = new Supplier<Exception>() {
@Override
import org.opendaylight.yangtools.yang.common.RpcError;
/**
- *
- * Failed commit of asynchronous transaction
- *
+ * Failed commit of asynchronous transaction.
* This exception is raised and returned when transaction commit
* failed.
*
<module>mdsal-common-api</module>
</modules>
-
<!--
Maven Site Configuration
Code Review / mdsal.git / commitdiff