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.
|Assignee||Knut Anders Hatlen [ knutanders ]|
|Status||Open [ 1 ]||In Progress [ 3 ]|
|Resolution||Fixed [ 1 ]|
|Fix Version/s||10.3.0.0 [ 12310800 ]|
|Status||In Progress [ 3 ]||Closed [ 6 ]|
|Component/s||Performance [ 11709 ]|
|Workflow||jira [ 12381834 ]||Default workflow, editable Closed status [ 12798439 ]|