To minimize overhead, the replicas should be deleted when they no longer of use, i.e. it is not in the area-of-interest of any primary object on the node. Similarly, replicas need to be deleted when the corresponding primaries have been deleted. In general, these deletions can be handled explicitly. For example, the replica receives a location update when the object moves and the object manager can easily compute if the replica is no longer in the node's area-of-interest. Similarly, an explicit deletion message is sent when primaries leave the system.
Since explicit deletions as well as other messages may be lost, the object manager uses a soft-state refresh mechanism for all replicas. Since a node periodically learns of its interests through the object location component (via fresh publications), it can use these publications to determine if it still requires a particular replica. A node can unregister interest in a replica when it does not receive publications for that replica for some time. In our current system, the node on which the replica resides periodically refreshes its interest in the primary (these can be piggy-backed on acknowledgments), and the node maintaining the primary discontinues sending deltas for a replica if it stops receiving interest refreshes. Note, that this soft-state mechanism also handles network partitions by removing interacting replicas from hosts that can not communicate with each other.