[
https://issues.apache.org/jira/browse/DERBY-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-1704:
--------------------------------------
Attachment: cleanup6.diff
Attaching a new small cleanup patch (cleanup6) for LockSet.java. LockSet has a
private Hashtable (lockTraces) into which it puts a Throwable each time a
thread must wait for a lock (only if deadlock tracing is enabled). The values
in the hash table are however never used, so the hash table and the code that
updates it could be removed. Derbyall and the JUnit tests ran cleanly with the
patch.
> 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, cleanup1.v2.diff, cleanup2.diff, cleanup3.diff, cleanup3.stat,
> cleanup4.diff, cleanup5.diff, cleanup5.stat, cleanup6.diff,
> 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.
-
You can reply to this email to add a comment to the issue online.
