[
https://issues.apache.org/jira/browse/DERBY-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545275
]
Knut Anders Hatlen commented on DERBY-3216:
-------------------------------------------
I noticed in the commit log that a fix had been committed (r597865).
I'm wondering, is the return in this finally clause in
purgeRowLevelCommittedDeletes() intentional? It will hide any exception thrown
in the try block and make the method return successfully, so it would be good
to add a comment explaining why it's there.
+ finally
+ {
+ if (controlRow != null)
+ controlRow.release();
+
+ return;
+ }
> do row level lock space reclamation in btree of indiv rows.
> -----------------------------------------------------------
>
> Key: DERBY-3216
> URL: https://issues.apache.org/jira/browse/DERBY-3216
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.1.4
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
>
> If you can't get a table level lock for btree space recovery in
> the post commit thread, maybe you should at least reclaim the
> rows on the page while you are at it. Use the same algorithm
> as exists in BTreeController.java. row level shrink is a different
> issue and won't be resolved by this.
> Note there have been reports of "memory" leaks associated with this issue.
> This is because
> currently if the work can not be done then we just queue it and move on. But
> in a stress situation
> one may never get the required table lock to shrink the tree and thus the
> queue just keeps growing.
> Note in many of these cases the app doesn't care if the page merge happens as
> it is just going to
> insert more rows after the merge.
> Also there is no need for a table level lock for a 1 page index as no merge
> is actually necessary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
