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 Thu, 10 Jan 2008 00:13:34 GMT

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

Mike Matrigali updated DERBY-1068:

The "rolling" data app is the paradigm that the existing derby algorithm should handle very
well with no need to call compress.
Rows in derby in the base table tend to cluster by page in the time they were inserted.  So
it should be the case that whole pages
of rows will be deleted and then be available for insert.  Assuming the rows are about the
same size.  If for instance one row is
480gb the rest are 100 bytes then compress is likely necessary once that one big row is deleted.
If everything is working right no need to ever call compress.  

Definitely if
you can reproduce the deadlock report in a new jira - we are off topic in this JIRA.  Note
if compress on 40 gb table takes 10 seconds, it is likely compress of 480 gb table will at
least take 100 seconds and probably a lot more as now data is probably
out of cache.  I think default timeout is 60 seconds.

> 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