[
https://issues.apache.org/jira/browse/DERBY-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4512:
--------------------------------------
Attachment: assert.diff
None of the tests in suites.All or derbyall call TransactionTable.add() on a
transaction that's already in the transaction table. I verified this by
applying the attached patch, assert.diff, which raises an assert failure if a
transaction with the same id is found, and running all the regression tests.
All of the tests passed.
> 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.
