[
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 purge.
> 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.
