I think I agree with Sergio here. By my reasoning if tryLock is going
to return false, then lock should block indefinitely. So lock being a
no-op and tryLock returning true, would seem to be the correct
pairing. I have to say I'm not so comfortable with the idea of
throwing exceptions though!
Chris
On Nov 16, 2009, at 11:34 AM, Sergio Bossa wrote:
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-forge-dev mailing list
tc-forge-...@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-forge-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
