[ 
http://issues.apache.org/jira/browse/DERBY-1704?page=comments#action_12449309 ] 
            
Knut Anders Hatlen commented on DERBY-1704:
-------------------------------------------

I am planning to partition the hash table in LockSet along the lines
of the split-hashtables.diff patch.

For the other hash table on which there is monitor contention (the one
in SinglePool), I think it is better to remove the hash table
entirely. That hash table maps a compatibility space to a
LockSpace. Since there is a one-to-one mapping between compatibility
spaces and LockSpaces, we could change it so that each compatibility
space is a LockSpace object and remove the need for the hash
table. This would (a) remove the contention problem, and (b) save some
CPU cycles because we don't have to go through the hash table.

If this sounds OK, I will create two sub-tasks: one for partitioning
the table in LockSet, and one for removing the table in SinglePool.

> Allow more concurrency in the lock manager
> ------------------------------------------
>
>                 Key: DERBY-1704
>                 URL: http://issues.apache.org/jira/browse/DERBY-1704
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services, Performance
>    Affects Versions: 10.2.1.6
>            Reporter: Knut Anders Hatlen
>         Assigned To: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: 1cpu.png, 2cpu.png, 8cpu.png, 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: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to