You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2010/01/12 16:09:54 UTC

[jira] Commented: (DERBY-3092) Use java.util.concurrent in TransactionTable to improve scalability

    [ https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799226#action_12799226 ] 

Knut Anders Hatlen commented on DERBY-3092:
-------------------------------------------

Dyre told me the test that hung was an appserver benchmark application, but he hadn't investigated whether the hang was caused by the patch or by something else. I'll see if I can get the application up and running myself and reproduce the hang.

I don't see anything obvious that could cause a hang in the patch. As far as I've understood how the synchronization in TransactionTable works, the changes suggested in xact-concept.diff look fine. (Except, of course, that we need to make it work on older Java versions too, and that some for loops are still unnecessarily synchronized on trans.)

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