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

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

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

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

I went through the TransactionTable class to get a picture of how the
synchronization is used there. It synchronizes on two different
objects: this (the TransactionTable) and trans (the Hashtable within
the TransactionTable). Many methods don't use any explicit
synchronization because they're guaranteed to be called only during
recovery, which is single-threaded.

* The explicit and implicit synchronization on the Hashtable is
basically used to prevent removal of elements from the Hashtable
between calls to Enumeration.hasMoreElements() and
Enumeration.nextElement(). (In addition to the obvious task of
protecting the consistency of the Hashtable's internal data structures
when modifying it from multiple threads.)

I think that ConcurrentHashMap's iterator gives the necessary
guarantees for most of these usages without any synchronization.

One potential problem is the method getTableForXA() which returns the
internal Hashtable. The caller then synchronizes on the returned
Hashtable while looping through it. If we are to provide two different
implementations, one of which not based on Hashtable, we probably need
to rethink how this is done.

* Synchronization on the TransactionTable is used to prevent
transaction table entries from state transitions between read
transactions and update transactions. This protection is needed when
writing the tx table during the checkpoint, since it scans the
transaction table twice, and the number of update transactions must be
equal both times. This synchronization probably needs to be preserved
in some way.

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