db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2327) Reduce monitor contention in LockSet
Date Fri, 09 Mar 2007 16:37:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479638

Daniel John Debrunner commented on DERBY-2327:

Thanks for the detailed writeup. This section has me confused though:

> I think this problem can be avoided by following a two-phase locking
> scheme when synchronizing on the entries of the lock table. That is,
> we lock the entries one by one as we see them, but don't unlock any of
> them until we have finished the traversal.

What does "lock the entries" mean here, java synchronization on the object, or logical lock
(e.g. row lock/table lock)?

I don't see how one could code so that java synchronization is kept on many objects without
deep stack nesting.

The entries are already logically locked so I'm not sure how locking them again would help?.

> 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