> interface TerracottaMap > 1: This interface is extended by ConcurrentDistributedMap, and as far > as I am aware the only implementors are the CDMImpl, and I'm guessing > the enterprise equivalent, perhaps we should be pushing some of the > more CDM specific methods down into the CDM interface? The only ones > I see as being really generic enough for TerracottaMap are > removeNoReturn, putNoReturn and tryRemove. > 2: Should we rename this to ClusteredMap (that might make choosing > the methods that remain in it easier... >
So, what I ended up doing was creating that ClusteredMap interface, but I put all the ConcurrentDistributedMap methods in it and got rid of the ConcurrentDistributedMap interface. I then renamed ConcurrentDistributedMapImpl to ConcurrentDistributedMap since I don't think we should have any *Impl concrete public classes. Of course, now the ClusteredMap interface has a whole bunch of methods that are somewhat TC specific, but the DistributedCache requires them apart from ConcurrentDistributedMap. I've gone through all of them, meaning to create a non public private interface for those that are really CDM-backend related, but there's none that isn't used by DistributedCache. There are thus two options, either we leave ClusteredMap as is, either we introduce an additional, optional interface that when a ClusteredMap implementation implements is, would enable more features in DistributedCache. The latter is relatively dangerous though, since it can cause eviction not to work in case this 'optional' interface isn't implemented. I'm leaning towards leaving ClusteredMap as is. > interface MapSizeListener > 1: Not amazingly happy that this is part of the public API. But I'm > not sure we can easily remove it... (anyone have any opinions here?) Same reasoning as above, don't see how to remove it either. > interface ConcurrentDistributedMap > 1: createFinegrainedLock - behavior on null key (are instance of CDM > allowed to implement the null key?) NPE, ConcurrentHashMap doesn't support null keys, so I'd say CDM shouldn't either. > 2: need to define local/non-local (based on local heap utilization I > guess) > 3: might gain some methods from TerracottaMap See above. > class ConcurrentDistributedMapImpl > 1: public __tc_ methods need to be removed from here. They are here > only so that the cluster info code can kind of work against the map. > Unfortunately this only works for getKeysForLocalValues, since all the > others defer to server calls which don't work against the top level > instance for various internal reasons. I'm thinking that what we > should do is stop this from having the __tc_ methods (and being > instrumented with TCMap) completely and instead either get the cluster > info code to call getConstituentMaps() directly or get the user to do > it from outside the cluster info code. I'm looking into this now, will post more later. > class DistributedSortedSet > 1: This is currently only used by tim-quartz and is highly quartz > specific. It doesn't implement either JDK Set or SortedSet. My > current plans are that we will attempt to upgrade this to at least > implement Set fully, if not SortedSet. If this turns out to be > impossible I think we are best off moving this into a private package > until we can clean up the class. This does have the negative effect > of making tim-quartz depend on non public API however. You currently moved this into a quartz package, right? I'd move this to com.terracotta then also, if it's just for quartz, it shouldn't be part of the public API. We can improve it in a next version. -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
