Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <26904668.1195515043257.JavaMail.jira@brutus>
Date: Mon, 19 Nov 2007 15:30:43 -0800 (PST)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Created: (DERBY-3216) do row level lock space reclamation in
 btree of indiv rows.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.