Fix checkstyle violations in sal-common-api

[controller.git] / opendaylight / md-sal / sal-common-api / src / main / java / org / opendaylight / controller / md / sal / common / api / data / TransactionChain.java

diff --git a/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java b/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java
index 12d9da696eaf108f0e06d733e252ef36044fd95d..c46910402d4d3092b9b053e421b922175186363a 100644 (file)
--- a/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java
+++ b/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java
@@ -15,25 +15,30 @@ import org.opendaylight.yangtools.concepts.Path;
  * 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.
  *
+ * <p>
  * 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
  * the asynchronous nature of transaction submission this can lead to surprising
  * results. If a thread executes the following sequence sufficiently quickly:
  *
+ * <p>
  * AsyncWriteTransaction t1 = broker.newWriteOnlyTransaction();
  * t1.put(id, data);
  * t1.submit();
  *
+ * <p>
  * AsyncReadTransaction t2 = broker.newReadOnlyTransaction();
  * Optional&lt;?&gt; maybeData = t2.read(id).get();
  *
+ * <p>
  * 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.
  *
+ * <p>
  * 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.
@@ -48,6 +53,7 @@ public interface TransactionChain<P extends Path<P>, D> extends AutoCloseable,
      * 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
@@ -71,12 +77,14 @@ public interface TransactionChain<P extends Path<P>, D> extends AutoCloseable,
      * 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-write transaction presents an isolated view of the data if the previous
      * write transaction was successful - in other words, this read-write 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.
+     *
      * <p>
      * Committing this read-write transaction using {@link AsyncWriteTransaction#submit submit}
      * will submit the state changes in this transaction to be visible to any subsequent
@@ -98,12 +106,14 @@ public interface TransactionChain<P extends Path<P>, D> extends AutoCloseable,
      * 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 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.
+     *
      * <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