db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3092) Use java.util.concurrent in TransactionTable and XactFactory to improve scalability
Date Sun, 07 Oct 2007 14:21:50 GMT

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

Dyre Tjeldvoll commented on DERBY-3092:
---------------------------------------

That could be very helpful! I'll keep it in mind. 

Unfortunately, it turns out that simply replacing the old Hashtable with ConcurrentHashMap
had some undesirable side-effects. They did not show up when running the simple d2911 client,
but caused strange hangs with more complicated load. I do believe it is possible to work around
that with better locking of the elements in the hash (as opposed to locking the entire hash),
but I've not had time to try that out yet...


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


Mime
View raw message