db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6873) handle btree rebalance case when it can't get table level lock.
Date Sun, 21 Feb 2016 18:57:18 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156165#comment-15156165

Mike Matrigali commented on DERBY-6873:

simple solution would be to give the rebalance operation a chance to run sometimes in post
commit.  Currently it is going to request a table lock
and if it can't get one it will retry later, but in active system never get a chance.    The
problem to solve is we want this operation to just wait for
the lock and run, but don't want all other post commit operations to wait behind it.

A solution would be another postcommit queue for these kinds of operations, and another thread.
 May not want the thread around always as some
derby usages  have 1000's of derby dbs in one server so adding 1000's of threads always is
an issue.

> handle btree rebalance case when it can't get table level lock.
> ---------------------------------------------------------------
>                 Key: DERBY-6873
>                 URL: https://issues.apache.org/jira/browse/DERBY-6873
>             Project: Derby
>          Issue Type: Improvement
>            Reporter: Mike Matrigali
> current implementation of btree requires table level lock on index to rebalance.  This
can result in inefficient tree structure if lock can not
> be obtained and if post commit retry also fails.  Similar to other problems
> if post commit retry does not succeed.
> May also leave unreclaimed space that could be reclaimed.
> Work around is to run compress on the table in offline mode.

This message was sent by Atlassian JIRA

View raw message