@Test
    public void testUpdateFromAnotherNodeForUnique() throws Exception
    {
        final ConcurrentMap<NodeID, Set<String>> reverseLookupMap = new ConcurrentHashMap<>();
        final ReverseLookupUpdatingCacheEntryListener<String, Set<NodeID>> listener = new ReverseLookupUpdatingCacheEntryListener<>(reverseLookupMap, true);
        final NodeID clusterNodeA = NodeID.getInstance(UUID.randomUUID().toString().getBytes());
        final NodeID clusterNodeB = NodeID.getInstance(UUID.randomUUID().toString().getBytes());

        // Execute system under test.
        listener.entryAdded("somekey", null, clusterNodeA);
        listener.entryUpdated("somekey", null, null, clusterNodeB);

        // Assert result
        assertFalse(reverseLookupMap.containsKey(clusterNodeA) && reverseLookupMap.get(clusterNodeA).contains("somekey"));
        assertTrue(reverseLookupMap.containsKey(clusterNodeB) && reverseLookupMap.get(clusterNodeB).contains("somekey"));
    }
Simulates a scenario where one cluster node adds an entry to an otherwise empty cache, followed by another
cluster node updating that entry, establishing itself as an 'owner' of the entry, with a listener that does not
allow entries to be owned by more than one cluster node.

In this scenario, the event listeners are fired in the same order as the order in which the insertions occur.
Due to the asynchronous behavior, this is not guaranteed to occur (see #testUpdateFromAnotherNodeForUniqueInWrongOrder).
xmppserver/src/test/java/org/jivesoftware/util/cache/ReverseLookupUpdatingCacheEntryListenerTest.java