A key difference between standalone JE and JE HA is that for standalone JE the environment is available for both reads and writes as long as the application (including the underlying hardware) is functioning correctly. That is, the availability of a standalone JE application is independent of the local durability policy set for the transaction. However, the distributed nature of JE HA, means that availability can be dependent upon the state of other nodes in the replication group. It can also be dependent upon the policies you set for your HA application.
JE HA requires that a simple majority of electable nodes be available to elect a Master. If a simple majority of those nodes is not available, the group is not available for writes because the group is unable to elect a Master.
In the presence of a Master, the availability of a replicated environment (at the Master) for write operations is determined by the durability requirements associated with the transaction:
If the transaction's durability requirements specify an acknowledgement policy of NONE, the Master is always available for write operations, just as is the case for standalone JE applications.
If the durability requirements are made more stringent and specify a simple majority for acknowledgements, or if all the electable group members must acknowledge transaction commits, the environment might not be available for writes when one or more of the Electable Replicas is unable to provide an acknowledgment. This loss of write availability can occur even in the absence of hardware failures.
Replicas might be unable to provide acknowledgements because a node is down. It could also occur if the Replica is simply lagging too far behind in the replication stream and so needs to commit earlier transactions before it can commit the current transaction. Note that in the absence of system level failures, the Replica will eventually commit the transaction, it just can not do so in the window of time required to indicate a successful commit of the transaction to the Master.
In other words, a durability policy that calls for commit acknowledgments can result in decreased availability of the system for write operations. It is important for you to keep this tradeoff in mind when choosing a durability policy.
A Master is always available for read operations because the data on it is always absolutely consistent. However, Replica read availability can be affected by the consistency policy that you are using:
A Replica is always available for read operations that do not have any read consistency requirements. That is, when the Replica is allowed to lag arbitrarily far behind the Master, then the Replica will always be available to service read requests.
If you are using higher levels of read consistency, then Replicas might not be available for read operations. This occurs when the Replica is forced to wait until it has caught up far enough in the replication stream before it can service a read operation. For example, if you choose a time consistency policy, and the the Replica cannot meet that consistency policy for a specific read operation, then the operation might be delayed or even abandoned entirely until the consistency policy can be met. This represents a loss of read availability.
There are many reasons why a Replica might not be able to meet a consistency policy. For example, the Master might be very busy and so is unable to supply the Replica with the replication stream fast enough. Or, it could be because the Replica is experiencing very heavy read loads and so the replication stream might not be fast enough to keep up. It is also possible that the Replica has been down and is trying to catch up, which means that it might not be able to meet a consistency policy.
All of these scenarios represent a loss of read availability, albeit a temporary one.
In other words, a consistency policy that requires the Replica to match the state of the Master to one degree or another can affect the Replica's read availability. It is important for you to keep this tradeoff in mind when choosing a consistency policy.