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