How different are our *Lock interfaces from their JDK equivalents? Can we just use the JDK ones instead?
Chris On May 19, 2010, at 11:31 AM, Geert Bevin wrote: > Hi, > > It was rightly brought up yesterday that there's not really a > consistent approach towards the naming of our public interfaces in > the toolkit. I'm sending out this email to start the discussion > about it. > > This is the current hierarchy for the app dev (the TIM dev has other > appropriate types also): > > org.terracotta > api > ClusteringProvider > cluster > TerracottaCluster > TerracottaClusterEvent > TerracottaClusterListener > TerracottaClusterTopology > TerracottaNode > UnclusteredObjectException > collections > MapSizeListener > TerracottaMap > coordination > Barrier > locking > FinegrainedLock > LockableMap > LockStrategy > LockType > ReadLock > ReadWriteLock > TerracottaLock > WriteLock > logging > TerracottaLogger > properties > TerracottaProperties > util > TextBucket > > java.util.concurrent.BlockingQueue > > So the instance of the ClusteringProvider interface is obtained by > instantiating StandaloneClusteringProvider and giving the URL of the > TC server as the constructor argument. > > Anything in the "cluster" package provides information that is > specific to the Terracotta cluster, which is why it's prefixed with > Terracotta. The same applies to TerracottaLogger and > TerracottaProperties, these are really bound to TC itself in that > they log into the TC log files and provide access to the properties > that TC uses. > > Then there's the TerracottaLock which does most basic lock > operations but with additional methods that makes sense for > Terracotta (currently only isHeldByCurrentThread for any lock > level). FinegrainedLock extends TerracottaLock in that it allows > lock levels to be passed in for each lock operation in a fine- > grained manner as opposed to have a default lock level for all > methods on the lock instance. LockableMap, LockStrategy and LockType > might have to be prefixed with Terracotta if we follow what I > explained until now since they're quite bound to our locking > features. ReadLock, ReadWriteLock and WriteLock are totally generic > locking functionalities. > > TextBucket basically is a StringBuilder that only provides you with > append(txt) and toString() so that there's a basic interface to > implement for clustered text storage. > > TerracottaMap is a regular ConcurrentMap that also implements > LockableMap, but adds more methods that are needed for optimal > cluster performance. It's not really TC-bound except for > implementing LockableMap so maybe we should rename it to ClusteredMap? > > There you have it ... rename away! ;-) > > Geert > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
