[
https://issues.apache.org/jira/browse/DERBY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472599
]
Knut Anders Hatlen commented on DERBY-2328:
-------------------------------------------
SinglePool's monitor is only locked when one needs to fetch the LockSpace
object associated with a compatibility space from SinglePool's hash table. A
hash table is used because the lock manager API says that any object can be a
compatibility space, and that two objects, a and b, refer to the same
compatibility space if a.equals(b) returns true. In the current Derby code,
there are no compatibility spaces that are considered equal by equals() that
are not considered equal by the == operator. Therefore, we could make the API
have stricter requirements to the compatibility space objects (for instance
that they must be == and created by a createCompatibilitySpace method) and
remove the hash table. Each compatibility space object would have a direct
reference to its locks. Since there would be no hash table to synchronize on,
the problem with monitor contention would be solved. Also, there would be less
indirection which could also be beneficial in the single-user case.
> Reduce monitor contention in SinglePool
> ---------------------------------------
>
> Key: DERBY-2328
> URL: https://issues.apache.org/jira/browse/DERBY-2328
> Project: Derby
> Issue Type: Sub-task
> Components: Performance, Services
> Affects Versions: 10.3.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> When multiple threads enter the lock manager, there might be contention on
> SinglePool's monitor. The contention should be reduced in order to improve
> scalability.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
