[
https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532968
]
Dyre Tjeldvoll commented on DERBY-3092:
---------------------------------------
That could be very helpful! I'll keep it in mind.
Unfortunately, it turns out that simply replacing the old Hashtable with
ConcurrentHashMap had some undesirable side-effects. They did not show up when
running the simple d2911 client, but caused strange hangs with more complicated
load. I do believe it is possible to work around that with better locking of
the elements in the hash (as opposed to locking the entire hash), but I've not
had time to try that out yet...
> Use java.util.concurrent in TransactionTable and XactFactory to improve
> scalability
> -----------------------------------------------------------------------------------
>
> Key: DERBY-3092
> URL: https://issues.apache.org/jira/browse/DERBY-3092
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.3.1.4
> Reporter: Dyre Tjeldvoll
> Attachments: xact-concept.diff
>
>
> Running scalability tests with the client and buffer manager from DERBY-2911
> shows that access to the TransactionTable.trans (a Hashtable) and
> XactFactory.tranId (a shared long) are the next major sources of contention.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
