Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <14966856.1199924014286.JavaMail.jira@brutus>
Date: Wed, 9 Jan 2008 16:13:34 -0800 (PST)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1068) change of store contract: online
 compress operations should not share any locks with user transactions
In-Reply-To: <1050477714.1141137643754.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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