X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?a=blobdiff_plain;f=opendaylight%2Fmd-sal%2Fsal-distributed-datastore%2Fsrc%2Fmain%2Fjava%2Forg%2Fopendaylight%2Fcontroller%2Fcluster%2Fdatabroker%2Factors%2Fdds%2FClientTransaction.java;fp=opendaylight%2Fmd-sal%2Fsal-distributed-datastore%2Fsrc%2Fmain%2Fjava%2Forg%2Fopendaylight%2Fcontroller%2Fcluster%2Fdatabroker%2Factors%2Fdds%2FClientTransaction.java;h=0a1c8be2471102db655b80359f63ebb5faa2cfd2;hb=a510fba141230ce9fe8301f9eb0198cc09df46ca;hp=e8e75e90e25c148d29ef73a5cf80debc0980ad77;hpb=314d5b41ea6b464db939da95a33c872f594ccada;p=controller.git 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 e8e75e90e2..0a1c8be247 100644 --- 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. * + *

* 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. * + *

* It is internally composed of multiple {@link RemoteProxyTransaction}s, each responsible for a component shard. * + *

* Implementation is quite a bit complex, and involves cooperation with {@link AbstractClientHistory} for tracking * gaps in transaction identifiers seen by backends. * + *

* 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. * + *

* 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. * + *

* 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. *