[ http://issues.apache.org/jira/browse/DERBY-1704?page=comments#action_12449382 ] Daniel John Debrunner commented on DERBY-1704: ----------------------------------------------
I haven't had time to look at the patch but the original intention was for there to be a multi-thread lock manager using multiple LockSets, e.g. a MultiPool implementation instead of a SinglePool implementation. Just FYI. With the multiple synchronization how is deadlock detection to be handled? > 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
