CDV ❯ locked TerracottaLock and TerracottaReadWriteLock instances before sharing are broken

• Type: Bug
• Status: Closed
• Priority: 2 Major
• Resolution: Fixed
• Component/s:
• Labels:

• Assignee: cdennis
• Reporter: teck
• Created: December 08, 2010
• Votes: 0
• Watchers: 0
• Updated:

  March 24, 2011
• Resolved:

  January 11, 2011

Description

If you have an instance of TerracottaReadWriteLock or a TerracottaLock (constructed with an unshared lock object), and then call any of the lock() methods, and then either share the TRWL or share the underlying lock object for TerracottaLock – you’ll get exceptions on unlock().

In custom mode we disallow sharing of already locked RL and RRWL instances, although the check is racy

Comments

Chris Dennis 2011-01-11

I’ve added pre-create methods for the TerracottaReadWriteLock that throw IllegalStateException if the lock is in any way locked when it is added to clustered heap. This gives us the same protection as the instrumented RRWL has in custom mode.

TerracottaLock does not require such a fix since it throws an IllegalArgumentException on construction if the supplied ‘monitor’ object is not clustered.