[
https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3092:
--------------------------------------
Attachment: derby-3092-5a-dynamic-loading.diff
derby-3092-5a-dynamic-loading.stat
Attached is a new patch (derby-3092-5a-dynamic-loading.diff) that implements
the dynamic loading of the correct Map implementation for the platform.
Ideally, I would have just added a couple of helper methods in XactFactory and
create a sub-class of XactFactory that overloaded the helper methods in order
to use ConcurrentHashMap instead of Hashtable, and then give the parent
XactFactory as an argument to TransactionTable's constructor. This could not be
done because TransactionTable is externalizable and it must be possible to read
it from a stream during recovery. When being read from a stream, it doesn't
know anything about which XactFactory it belongs to.
Instead, I made the first instance of XactFactory that's being created set a
static field in XactFactory to point to a TransactionMapFactory object.
TransactionMapFactory contains helper methods to create and iterate over a map,
and there are two implementations (one for Hashtable and one for
ConcurrentHashMap). Then TransactionTable's constructor can call a static
accessor method in XactFactory to get hold of that object, and create a map of
the type that gives the highest level of concurrency on that platform.
I've run all the regression tests on Java 1.4.2, Java 1.5.0 and Java 1.6.0 with
no failures, and the d2911perf test shows improvements similar to those seen
with Dyre's initial patch.
I don't think the patch is ready for commit yet, but I'm posting it here for
reference. Now it is possible that multiple threads access fields in the same
TransactionTableEntry object concurrently, which was not possible before when
all iteration over the values would be protected by synchronization on trans.
It might be that some entry-level synchronization will be needed, as Dyre
suggested in an earlier comment. I'll do some more investigation on whether the
mutable state of TransactionTableEntry is still protected, or if we have to add
another level of synchronization. I'm optimistic, though, that even if we have
to add synchronization on the entry level, it should not affect the performance
gain seen in the earlier patches very much, since those monitors will not be
nearly as contended as the one on the Hashtable.
> Use java.util.concurrent in TransactionTable 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
> Assignee: Knut Anders Hatlen
> Attachments: derby-3092-1a-map.diff, derby-3092-1b-map.diff,
> derby-3092-2a-count.diff, derby-3092-3a-xa-visitor.diff,
> derby-3092-4a-more-visitors.diff, derby-3092-5a-dynamic-loading.diff,
> derby-3092-5a-dynamic-loading.stat, xact-concept.diff, xact-concept.png
>
>
> 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.
