[
https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785039#action_12785039
]
Knut Anders Hatlen commented on DERBY-3092:
-------------------------------------------
I reran Dyre's experiment on the same kind of machine, but with a newer JVM
(early access release of JDK 7) and head of trunk. I used a slightly different
test client that's available in derbyTesting.jar (java
org.apache.derbyTesting.perf.clients.Runner -load sr_select_multi). It still
looks like the patch improves the scalability for this kind of load.
The xact-concept.diff patch actually consists of two independent changes:
1) The tranId field in XactFactory is changed into an AtomicLong, and the
synchronization that protects it is removed. This looks like a safe change (but
some extra work is required to make it also work on pre-Java 5).
2) The Hashtable in TransactionTable is changed into a ConcurrentHashTable. As
Dyre noted, this change was not safe the way it appeared in the patch, and some
more synchronization is needed (hopefully most of it can be added on the entry
level to avoid locking the entire map). Making it work on pre-Java 5 platforms
is required for this change too.
When I ran the experiment, I tried to run with these two changes separately as
well as combined. I was not able to detect any changes in the performance with
change (1), whereas (2) seemed to give a good improvement. Based on that, I
think it's best to focus on (2) first. Perhaps it would also make sense to
split this JIRA issue into two separate issues.
> 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: 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.
