Fix remaining CS warnings in sal-distributed-datastore

[controller.git] / opendaylight / md-sal / sal-distributed-datastore / src / main / java / org / opendaylight / controller / cluster / databroker / actors / dds / ClientTransaction.java

diff --git a/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/databroker/actors/dds/ClientTransaction.java b/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/databroker/actors/dds/ClientTransaction.java
index e8e75e90e25c148d29ef73a5cf80debc0980ad77..0a1c8be2471102db655b80359f63ebb5faa2cfd2 100644 (file)
--- a/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/databroker/actors/dds/ClientTransaction.java
+++ b/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/databroker/actors/dds/ClientTransaction.java
@@ -27,22 +27,28 @@ import org.slf4j.LoggerFactory;
 /**
  * Client-side view of a free-standing transaction.
  *
+ * <p>
  * This interface is used by the world outside of the actor system and in the actor system it is manifested via
  * its client actor. That requires some state transfer with {@link DistributedDataStoreClientBehavior}. In order to
  * reduce request latency, all messages are carbon-copied (and enqueued first) to the client actor.
  *
+ * <p>
  * It is internally composed of multiple {@link RemoteProxyTransaction}s, each responsible for a component shard.
  *
+ * <p>
  * Implementation is quite a bit complex, and involves cooperation with {@link AbstractClientHistory} for tracking
  * gaps in transaction identifiers seen by backends.
  *
+ * <p>
  * These gaps need to be accounted for in the transaction setup message sent to a particular backend, so it can verify
  * that the requested transaction is in-sequence. This is critical in ensuring that transactions (which are independent
  * entities from message queueing perspective) do not get reodered -- thus allowing multiple in-flight transactions.
  *
+ * <p>
  * Alternative would be to force visibility by sending an abort request to all potential backends, but that would mean
  * that even empty transactions increase load on all shards -- which would be a scalability issue.
  *
+ * <p>
  * Yet another alternative would be to introduce inter-transaction dependencies to the queueing layer in client actor,
  * but that would require additional indirection and complexity.
  *