This is referring to: https://jira.jboss.org/jira/browse/JBCACHE-841 And rather than exposing the backing Map impl to users, I'd prefer to just provide a few settings on a node such that: | Node.isDataOrdered(); // tests if the data map is ordered | Node.isChildrenOrdered(); // tests if the child map is ordered | Node.setDataOrdered(boolean b); // locks the map, and then copies out the existing data map into a new ordered map structure | Node.setChildrenOrdered(boolean b); // similar to above | Is there anything else we'd need? Using iterators on the sets and maps returned when accessing data/data-keys/children/children-names will be ordered if the node is set to be ordered. I guess perhaps providing comparators if the data has no natural ordering would be useful? This comparator would have to be serializable though if it is to be replicated/persisted. | Node.setDataComparator(Comparator<K> c); | I'm guessing we'd need a SortedMap similar to FastCopyHashMap that is optimised for copying/cloning? Finally, these settings would have to be replicated/persisted. I'm guessing there should be no special options on cache loaders, but when the data is loaded into the node it would be ordered by the map implementation. Also, I see this as a per-node option. Any thoughts on whether this would be useful as a cache-wide cfg option? There may be cases where a thread is reading a node in a tx, and another thread sets it's sorted flag to true. I'm guessing flag changes like these are considered a write operation since the map implementation changes and a copy of contents will take place. Or - to make life easier - do we want this to be cache-wide so that all nodes are either sorted or not, and there is no issue with changing them? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168143#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...