Hi All,
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.
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.
Anyway, my thoughts on the locking classes follow,
Chris
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)
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
2: If we do the above, given the inclination towards non TC specific
names for interfaces should this be ClusteredLock?
interface LockableMap
interface LockStrategy
1: seems like these belong in the collections package - or a sub-
package of same
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?
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)
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?
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.
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?
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
