[
https://issues.apache.org/jira/browse/DERBY-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4512:
--------------------------------------
Attachment: txtab.diff
txtab-noblanks.diff
Here's a patch that makes the suggested change (txtab.diff). The patch looks
somewhat messy because much code is moved up one indentation level because an
if statement is removed. I've therefore also attached a patch generated with
svn diff --extensions="-ub" which ignores whitespace changes, to make it easier
to see exactly what has changed (this patch is called txtab-noblanks.diff).
The patch changes TransactionTable.add() in the following ways:
1) It does not call findTransactionEntry(id) first and checks the return value.
2) The return value from trans.put(id, ent) is captured, and an assert is added
to verify that it is null (that is, the entry was not already there).
3) An assert that checked that the existing entry had the same exclusion as the
one we attempt to add, is removed. This is because we now assert that there is
no existing entry, which is a stricter condition.
TransactionTable.add() uses a mix of tabs and spaces for indentation. I chose
to use spaces consistently for my changes.
All the regression tests ran cleanly with the patch.
> 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, txtab-noblanks.diff, txtab.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.
