The new transaction management API exposed by the REST service has specific semantics for HA. In particular, HA nodes do not coordinate when transactions are created and aborted/committed. All coordination is in terms of the ACID 2-phase commit protocol when the nodes communicate to obtain a consensus for the new release time. Thus, load balancing of read operations is possible, but the client MUST use the readsOnCommitTime to issue reads against followers (and MAY use this to issue reads against the leader).
We need tests for the following:
- LBS directs all transaction management requests to the leader (including things like STATUS-TX). Followers reject transaction management requests if they arrive at their non-load balanced interface.
- An aware client can load balance queries across the leader and followers using the readsOnCommitTime. Those reads should have snapshot isolation. In particular, the commit point should remain visible while the transaction is active and concurrent commits should not become visible to read operations that are isolated by the transaction (including the case of read operations using the readsOnCommitTime).
- The leader accepts mutation operations that are isolated by a transaction. If the mutation is addressed to a namespace that supports isolation, then it is accepted. If the mutation is addressed to a namespace that does not accept mutation, then an error is reported (BAD_REQUEST). (This is identical for the non-HA transaction management API but we need to test it for HA as well.)
This does raise the question of the extent to which the BigdataSailRemoteRepositoryConnection supports the HA load balancer.
See BLZG-1195 Read/write tx support in NSS and BigdataSailRemoteRepositoryConnection