[
https://issues.apache.org/jira/browse/DERBY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-2327:
--------------------------------------
Attachment: ConcurrentHashMap.diff
I agree that ConcurrentHashMap is the way to go. ConcurrentHashMap.diff is an
experimental patch which replaces the HashMap in LockSet with a
ConcurrentHashMap. It seems to have good effect on the 1000x10000 join load
from DERBY-1961 on multi-CPUs. It doesn't come for free in single-user
environments though, but that could just as well be caused by stupid
implementation by me. Note that the patch is in a very experimental state. It
runs, but exotic features like deadlock detection certainly don't work. Also,
in its current state it requires JDK6 to compile and run.
> Reduce monitor contention in LockSet
> ------------------------------------
>
> Key: DERBY-2327
> URL: https://issues.apache.org/jira/browse/DERBY-2327
> Project: Derby
> Issue Type: Sub-task
> Components: Performance, Services
> Affects Versions: 10.3.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
> Attachments: ConcurrentHashMap.diff
>
>
> When multiple threads enter the lock manager, only one can access the hash
> table in LockSet. To improve scalability on multiple CPUs, it should be
> possible to have more than one thread accessing the lock table at the same
> time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
