[
https://issues.apache.org/jira/browse/DERBY-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799243#action_12799243
]
Knut Anders Hatlen commented on DERBY-4512:
-------------------------------------------
Thanks Bryan. I was thinking that we could check the return value from
Hashtable.put(), which should be null if there was no previous mapping
registered for that transaction id.
I tried such a change with the d2911perf client used in DERBY-3092 on a 32-way
system. With 32 threads, trunk performed 158K tx/s and the patched version 182K
tx/s, which means about 15% improvement.
Still, this patch is far less effective than Dyre's patch that replaces the
Hashtable with a ConcurrentHashMap. With that patch, I saw 230K tx/s. It is
however possible to combine those two patches and get an additional 3-4%
increase in the throughput on top of that, it seems, so I think it's going to
be beneficial regardless of how/if we end up addressing DERBY-3092.
Another thing I've noticed with TransactionTable.add() is that the
synchronization on TransactionTable.this is probably not needed (will file
another JIRA issue for that). My understanding is that synchronization on
TransactionTable.this is used to protect transaction state changes from read to
update. No such transition happens within that synchronized block, so the
(implicit) Hashtable synchronization should be enough.
> Avoid unnecessary lookup in transaction table when adding transaction
> ---------------------------------------------------------------------
>
> Key: DERBY-4512
> URL: https://issues.apache.org/jira/browse/DERBY-4512
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: assert.diff
>
>
> TransactionTable.add() first checks if the Hashtable trans contains a
> transaction with the same id as the one being added. If it does, add() does
> nothing. If there is no such transaction, a new TransactionTableEntry is
> created and put into the Hashtable.
> I believe that TransactionTable.add() is never called on a transaction that
> has already been added to the table. If this is the case, there's no point in
> checking the Hashtable first. Instead, we could just create a new
> TransactionTableEntry and add it unconditionally. This would reduce the
> number of (synchronized) Hashtable calls and could improve the performance in
> scenarios like the one described in DERBY-3092.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
