[
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-3a-xa-visitor.diff
I think the next step is to encapsulate the Hashtable inside the
TransactionTable class. Currently, this internal data structure is exposed
through the method getTableForXA(). XactXAResourceManager uses this method to
get a reference to the Hashtable, and synchronizes on the Hashtable while
iterating over it. It will be easier to replace the Hashtable with a
ConcurrentHashMap if no other classes depend on it being a Hashtable.
In the attached patch (derby-3092-3a-xa-visitor.diff) I have removed the
getTableForXA() method and instead introduced a visitor that can be used to go
through the elements of the transaction table. The patch also makes
XactXAResourceManager use the visitor instead of accessing the Hashtable
directly.
I believe that the proposed patch also fixes a bug in
XactXAResourceManager.recover(). That method initializes an array with the same
size as the transaction table outside the synchronized block. If a new entry is
added to the tx table in the window between the call to Hashtable.size() and
the start of the synchronized block, an ArrayIndexOutOfBoundsException may be
raised while populating the array. With the patch, we no longer use
Hashtable.size() to initialize an array, so this situation can't occur anymore.
Running regression tests...
> 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, 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.
