[
https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803246#action_12803246
]
Knut Anders Hatlen commented on DERBY-3092:
-------------------------------------------
Now there are only a few places in the code that synchronize explicitly on
trans. These are methods doing linear search of the transaction table,
primarily during checkpoint and for diagnostics, as well when a global XA
transaction is started.
These are the methods doing linear search with explicit synchronization on
trans:
findTransactionContextByGlobalId
writeExternal
getFirstLogInstant
getTransactionInfo
In addition you have hasActiveUpdateTransaction() whose comments indicate that
synchronization on trans is needed, but it currently only synchronizes on
"this". And in sane builds, toString() is called from within the synchronized
block in getTransactionInfo() and performs a linear search.
If we change the above mentioned methods so that they use visitors instead of
iterating through the transaction table themselves, we will have explicit
synchronization on trans in just one method - visitEntries(). Having just a
single method to override when adding ConcurrentHashMap sounds attractive, so I
will attempt to make such a change.
There are more methods that search the Hashtable linearly, but without
synchronization because they are only called during boot/recovery, according to
their comments. These methods are:
hasRollbackFirstTransaction
hasPreparedXact
getMostRecentRollbackFirstTransaction
getMostRecentTransactionForRollback
getMostRecentPreparedRecoveredXact
These methods do not need any changes when switching between Hashtable and
ConcurrentHashMap, because they are only used when the engine is running
single-threaded, and they do not depend on the synchronization properties of
Hashtable.
> 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.
