Features:
Transparent, transactional, high performance replication of object data across nodes.
Transparent routing of data to a partition or node.
High performance, automated support for migration of object ownership from a failed active node to a replica node.
Cost:
Additional CPU cycles and memory resources for managing the internal transaction resources when modifying a Managed object. Additional network I/O for propagating the modifications to the replica nodes.
Reads of highly available objects have the same performance as reads of Managed objects. No extra cycles are consumed and no network I/O is generated.
Usage:
Use highly available objects to provide non-stop access to application data in the case of node failure.
Use partitions with multiple replica nodes to provide a transparent, transactional push mechanism of object data to a group of nodes.
Use highly available objects methods to execute behavior on the currently active node for a partition.
Use highly available objects to transparently scale an application load horizontally across multiple nodes.
Avoid:
Modifying highly available objects unnecessarily. Modifications cause network I/O and processing cycles on the replica nodes. If there is data being modified that is not necessary for the application to see after a fail-over, do not keep this data in a highly available object. Use either Managed objects or POJOs.
Note, that in comparision to Managed objects and POJOs, a highly available object incurs extra processing costs even when there are no replica nodes defined for its partition.
Making highly available objects larger than necessary. Each time a modification occurs, the entire object is copied to the replica nodes.
Replicating object data to more nodes than is required. Each additional replica node requires additional network I/O and processing.
For simple load balancing consider using a hardware based solution instead of the location transparent routing provided by highly available objects.