On Mon, Nov 16, 2009 at 3:41 PM, Geert Bevin <gbe...@terracottatech.com> wrote:
> I personally think it should return false since the lock is never acquired in > FinegrainedLockNoDso. The lock() method doesn't acquire any actual lock either: so lock() and tryLock() doesn't behave the same. Following your thoughts, then, lock() should throw UnsupportedOperationException. > If this class is rewritten to do actual locking on meaning entities, then the > return value could should, but now with its no-op implementation I think it's > good > to be correct and not give out any false guarantees. Again, if this is your point, then lock() and tryLock() should both throw an UnsupportedOperationException, or even better, a meaningful exception that clients could properly handle: if you just return false, there's no way to understand if it wasn't actually able to acquire the lock, or rather there was actually no lock to acquire. What do you think? Thanks, Cheers, Sergio B. -- Sergio Bossa Software Passionate and Open Source Enthusiast. URL: http://www.linkedin.com/in/sergiob _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
