On May 26, 2010, at 2:49 PM, Geert Bevin wrote: >> Besides the questions below there is the question of what the >> behavior >> should be when a lock upgrade is attempted. This is when a thread >> holds a read lock, and attempts to take a write lock. In core TC >> this >> has always resulted in the throwing of a >> TCLockUpgradeNotSupportedException. This behavior has however caused >> some problems when attempting to code flexibly for both JDK locking >> and TC locking since the behavior of the JDK is to block, either >> indefinitely in the case of lock, or for the required amount of time >> in the case of tryLock. Personally I would prefer to match the >> behavior of the JDK. > > I think that this might stem from the original behavior of the auto- > locking and how methods can be marked as read locked or write > locked. Having an application block just due to TC locking being > activated was probably not a good idea. It does seem that for lock > classes we would ideally want to mimic the JDK behavior, I'm just > not certain that we can do both underneath the covers. What do you > think Chris? > Should be able to catch the TC exception in the toolkit impl's and do Thread.sleep(), return false or Thread.join() in the handler.
>> If we decide to keep the exception throw behavior then we also have >> to >> decide whether we want to explicitly declare this exception to be >> thrown from the locking methods. If we take this path then we will >> have to wrap the TCLockUpgradeNotSupportedException in a toolkit >> public type to maintain the type closure of the public API. > >> interface TerracottaLock >> 1: This seems absurdly close to j.u.c.l.Lock to me... (its only got >> isHeldByCurrentThread() as an extra and is missing lockInterruptibly >> which we can support) > > isHeldByCurrentThread seems to be only used by tests. I think we can > remove it and require those tests to use FinegrainedLock instead. > Then we can just adopt the Lock interface. > I'll make those changes then >> interface FinegrainedLock extends TerracottaLock >> 1: Now this seems a lot more like a TerracottaLock... perhaps we >> should push the isHeldBy... into here and make this TerracottaLock >> and >> make the old TerracottaLock just Lock > > ... should have read until here ... :-) > and these ones >> 2: If we do the above, given the inclination towards non TC specific >> names for interfaces should this be ClusteredLock? > > We haven't decided on that yet, but if we do, yes it should be > renamed. > >> interface LockableMap >> interface LockStrategy >> 1: seems like these belong in the collections package - or a sub- >> package of same > > Imho they feel more natural in the locking package. > >> enum LockType >> 1: The lock types talk about Terracotta specific concepts (e.g. the >> TC Server Array). Should we attempt to generalize the concepts and >> language here? > > Don't think we should generalize the naming here, maybe just work on > the docs. > >> 2: The lock types should mention their exclusion properties... (even >> though this may be obvious...) >> >> class FinegrainedLockDso >> class FinegrainedLockNoDso >> 1: These are only used by the ConcurrentDistributedMap. I propose >> that they should be moved out of the public API (in to >> com.tc.toolkit.locking) > > I was actually sort of thinking of doing work on them to allow > people to instantiate them directly without having to go through the > CDM. > How would they be any different to a TerracottaLockImpl with a string argument? >> class SharedReadWriteLock >> 1: onLoad method shouldn't be public (need to double check that this >> will play nice with the applicator...) >> 2: What happens to existing lock holds when we change the sync write >> state while the lock is held? > > Good question, any ideas? > My first instinct is to just say that we throw the IllegalMonitorState, as the normal usage pattern would be to change this on lock creation and then never touch it... Makes me wonder if it should actually be a constructor argument. >> class SharedConditionObject >> 1: Public constructors should be package protected here, firstly no >> reason for a user to construct one directly, and secondly one of the >> constructors leaks a core type into the public API. > > Right! > >> class TerracottaLockImpl >> 1: If we rework the interfaces as above, should this class implement >> j.u.c.l.Lock or the new TerracottaLock? >> 2: What happens if we pass in an unclustered object to the >> constructor? > > IllegalArgumentException > >> 3: What happens if that unclustered object subsequently becomes >> clustered? >> _______________________________________________ >> tc-dev mailing list >> tc-dev@lists.terracotta.org >> http://lists.terracotta.org/mailman/listinfo/tc-dev > > -- > 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
