A DESCRIPTION OF THE REQUEST :
Remove lock in AbstractPreferences.parent()
Change the method from:
public Preferences parent() {
synchronized(lock) {
if (removed)
throw new IllegalStateException("Node has been removed.");
return parent;
}
}
to:
public Preferences parent() {
if (removed)
throw new IllegalStateException("Node has been removed.");
return parent;
}
JUSTIFICATION :
When implementing concrete Preferences we need to get the parent() of the Preferences. According to the spec the methods may be called with a child lock held in which case we can't traverse up the tree as the specs also say locks have to be acquired top down (parent then child). Calling parent() currently does in fact cause Deadlock a lot of the time.
The synchronization here does nothing an in fact just slows down the code. If the lock was held prior to this call then it achieves nothing and if it wasn't held then after this method returns (releases the lock) then removeNode() could be called before the callee uses the parent.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No lock to be used and hence no deadlock.
ACTUAL -
The lock is used and hence there can be deadlock.
CUSTOMER SUBMITTED WORKAROUND :
In the concrete class store parent there as well and overwrite parent() to return that parent instead.
###@###.### 2005-06-24 14:13:53 GMT
Remove lock in AbstractPreferences.parent()
Change the method from:
public Preferences parent() {
synchronized(lock) {
if (removed)
throw new IllegalStateException("Node has been removed.");
return parent;
}
}
to:
public Preferences parent() {
if (removed)
throw new IllegalStateException("Node has been removed.");
return parent;
}
JUSTIFICATION :
When implementing concrete Preferences we need to get the parent() of the Preferences. According to the spec the methods may be called with a child lock held in which case we can't traverse up the tree as the specs also say locks have to be acquired top down (parent then child). Calling parent() currently does in fact cause Deadlock a lot of the time.
The synchronization here does nothing an in fact just slows down the code. If the lock was held prior to this call then it achieves nothing and if it wasn't held then after this method returns (releases the lock) then removeNode() could be called before the callee uses the parent.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No lock to be used and hence no deadlock.
ACTUAL -
The lock is used and hence there can be deadlock.
CUSTOMER SUBMITTED WORKAROUND :
In the concrete class store parent there as well and overwrite parent() to return that parent instead.
###@###.### 2005-06-24 14:13:53 GMT