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] Updated: (DERBY-1068) change of store contract: online compress operations should not share any locks with user transactions
Date Wed, 09 Jan 2008 00:40:34 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-1068:

What I was trying to say is that derby will use allocated space that has been "freed" by committed
deletes in some cases for subsequent inserts.  Derby does not return the space to the OS,
but it tracks the deleted space in the table and often after deletes it can use existing space
within the table without asking the OS for more space to executes
inserts.  This tends to work well when the total amount of space for inserts is greater than
the total amount of space of deletes.  Once the space of deletes is greater than expected
future inserts than
there is dead space that can only be returned to OS through one of the compress table calls.
 A worst case example is an app which inserts 500gb of data and then deletes it all, and subsequently
has no plans to insert much more. 

The lock deadlock error looks wierd, and probably should not happen.

A lock timeout error is likely expected behavior for competing inserts to the offline compress
table operation depending on how big the table you are compressing, machine speed, disk speed
and settings for lock timeout wait and lock deadlock wait.  These timeouts are configurable
and can be set to wait forever if you would rather not see a lock timeout error.  In most

cases the defaults for these are reasonably high - but the time to compress a 500 GB table
is likely much longer than most settings of lock timeout.

If you can come up with a reproducible case for the deadlock error (vs. timeout), please contribute
it under a new JIRA entry.  

> change of store contract: online compress operations should not share any locks with
user transactions
> ------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1068
>                 URL: https://issues.apache.org/jira/browse/DERBY-1068
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>            Reporter: Andreas Korneliussen
>            Assignee: Mike Matrigali
>            Priority: Minor
> Propose to add the following to the store contract:
> * truncate and compress requires exclusive table locking
> * the truncate, purge and compress operations do not share any locks with user transactions

> Currently the store implementation allows users to share locks in truncate and possibly
> This request is driven by:
> http://www.nabble.com/conflict-detection-strategies-t1120376.html#a2938142
> and:
> http://www.nabble.com/RowLocation-contract-from-storage-engine-t1142235.html#a2994156

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

View raw message