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] Commented: (DERBY-1704) Allow more concurrency in the lock manager
Date Mon, 22 Jan 2007 13:33:30 GMT

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

Knut Anders Hatlen commented on DERBY-1704:
-------------------------------------------

Thank you for looking at the patch! I'll try to answer your questions below.

1) The change of LockSet from "public final" to "final" was intentional. LockSet is an internal
implementation class that is not supposed to be accessed from other packages.

2) I'm not sure what the exact meaning of the MT comment is. I would assume that it meant
something like "calls to public (or non-private) methods of this class can be regarded as
atomic operations". I'm not sure that this statement is completely true before the patch,
but it is definitely not true after the patch, so the comment should be updated.

3) getWaiters() is a private helper method for Deadlock.look() which is only invoked from
inside a synchronized block in LockSet, so getWaiters() is in fact always synchronized on
the LockSet. This would probably have been clearer if Deadlock.look() had one of those infamous
MT comments. :) I'll add one.

> 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, 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message