db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2327) Reduce monitor contention in LockSet
Date Mon, 05 Mar 2007 19:11:50 GMT

     [ 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

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:
>            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.

View raw message