From another thread that I started by mistake.
"manik.surtani(a)jboss.com" wrote :
| 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=4168758#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...