[
https://issues.apache.org/jira/browse/DERBY-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466462
]
Knut Anders Hatlen commented on DERBY-1704:
-------------------------------------------
Thank you for looking at the patch! I'll try to answer your questions below.
1) The change of LockSet from "public final" to "final" was intentional.
LockSet is an internal implementation class that is not supposed to be accessed
from other packages.
2) I'm not sure what the exact meaning of the MT comment is. I would assume
that it meant something like "calls to public (or non-private) methods of this
class can be regarded as atomic operations". I'm not sure that this statement
is completely true before the patch, but it is definitely not true after the
patch, so the comment should be updated.
3) getWaiters() is a private helper method for Deadlock.look() which is only
invoked from inside a synchronized block in LockSet, so getWaiters() is in fact
always synchronized on the LockSet. This would probably have been clearer if
Deadlock.look() had one of those infamous MT comments. :) I'll add one.
> Allow more concurrency in the lock manager
> ------------------------------------------
>
> Key: DERBY-1704
> URL: https://issues.apache.org/jira/browse/DERBY-1704
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Services
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Minor
> Attachments: 1cpu.png, 2cpu.png, 8cpu.png, cleanup1.diff,
> cleanup1.stat, split-hashtables.diff, split-hashtables.stat
>
>
> I have seen indications of severe monitor contention in SinglePool
> (the current lock manager) when multiple threads access a Derby
> database concurrently. When a thread wants to lock an object, it needs
> to obtain the monitor for both SinglePool and LockSet (both of them
> are global synchronization points). This leads to poor scalability.
> We should investigate how to allow more concurrency in the lock
> manager, and either extend SinglePool or implement a new manager.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
