Hi All,
More API spec discussion...
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...
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?)
class ConcurrentBlockingQueue
1: already implements a standard JDK interface so large parts of spec
are bolted down... don't anticipate this being a problem
interface ConcurrentDistributedMap
1: createFinegrainedLock - behavior on null key (are instance of CDM
allowed to implement the null key?)
2: need to define local/non-local (based on local heap utilization I
guess)
3: might gain some methods from TerracottaMap
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.
class ConcurrentDistributedSet
1: simple JDK Set impl using CDM as a backing... don't anticipate
this being a problem
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.
Chris
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
