db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3216) do row level lock space reclamation in btree of indiv rows.
Date Sun, 25 Nov 2007 16:31:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545278

Knut Anders Hatlen commented on DERBY-3216:

In the same method, I see this piece of code:
+            if ((controlRow = ControlRow.get(open_btree, page_number)) == null)
+                return;

As far as I can see, it is impossible that ControlRow.get() returns null, so by returning
successfully when controlRow is null, we might be hiding future bugs. Wouldn't it be better
to skip the null checking and just let the method fail with an NPE when controlRow is dereferenced?

> 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:
>            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
> 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message