• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • hhuynh
  • Reporter: teck
  • January 26, 2008
  • 0
  • Watchers: 0
  • April 25, 2008
  • January 26, 2008



I’ll attach some thread dumps of this in action, but the problem starts when the memory manager in the client calls __tc_clearReferences() on ConcurrentHashMap. The memory manager always takes the TCObject resolve lock before calling __tc_clearReferences(). In ConcurrentHashMap, __tc_clearReference() also takes distributed locks (on the segments), this particular nesting is problematic. In order to obtain the segment locks, txns from other nodes might need to be applied locally. Those incoming txns will need to obtain the resolve lock to apply(), thus you end up with a deadlock.

The fix is to not take distributed locks on the segments (local only)

This has been making the ConcurrentHashMapSwapingTest fail for quite a while