db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3092) Use java.util.concurrent in TransactionTable to improve scalability
Date Fri, 05 Feb 2010 12:03:27 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-3092:

    Issue & fix info: [Patch Available]

As far as I can see, none of the code that currently synchronizes on the Hashtable modifies
any shared state outside of the Hashtable itself, so the only purpose of this synchronization
appears to be to make the Hashtable operations atomic. This is also ensured by ConcurrentHashMap,
so I've come to the conclusion that we don't need to add any new synchronization level when
we remove "synchronized (trans)" around the for loops. Setting the Patch Available flag to
record that I think the patch is ready for review.

I will need to run more tests in order to fully convince myself that the changes are fine.
Should we however commit the patch earlier in order to get as much testing as possible? If
it's getting closer to the release date and we feel that we don't yet have the required level
of confidence in the new code, it could easily be disabled by commenting out a couple of lines
in modules.properties and we would fall back to the old, well-tested code on all platforms.

> 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:
>            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.

View raw message