[
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
(v6.3.4#6332)
