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