[
https://issues.apache.org/jira/browse/DERBY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-2327:
--------------------------------------
Attachment: derby-2327-1a.stat
derby-2327-1a.diff
To make it easier to plug in another LockSet implementation, LockSet should be
better encapsulated. I'm attaching a patch (derby-2327-1a) which makes these
changes:
- creates a new interface (LockTable) which LockSet implements
- replaces all references to LockSet with references to the new LockTable
interface
- moves code that explicitly synchronizes on the LockSet object from
LockSpace.unlockReference() and SinglePool.zeroDurationlockObject() to LockSet
so that the granularity of the synchronization can be controlled by the LockSet
implementation alone
- adds setter methods for deadlock timeout and wait timeout
Derbyall and suites.All passed on Solaris 10, Java SE 6.
> 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
> Assigned To: Knut Anders Hatlen
> Priority: Minor
> Attachments: ConcurrentHashMap.diff, derby-2327-1a.diff,
> derby-2327-1a.stat
>
>
> 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.
