Class ClientTransaction

  • All Implemented Interfaces:
    Identifiable<TransactionIdentifier>

    @Beta
    public class ClientTransaction
    extends AbstractClientHandle<org.opendaylight.controller.cluster.databroker.actors.dds.AbstractProxyTransaction>
    Client-side view of a 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 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 RemoteProxyTransactions, each responsible for a component shard.

    Implementation is quite a bit complex, and involves cooperation with 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.

    Author:
    Robert Varga