db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "quartz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1068) change of store contract: online compress operations should not share any locks with user transactions
Date Fri, 04 Jan 2008 00:45:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555742#action_12555742

quartz commented on DERBY-1068:

I have had a serious problem with SYSCS_UTIL.SYSCS_COMPRESS_TABLE.

On separate connections and separate yet concurrent threads (obviously)
I try to pack my table while insert are ongoing, basically like this:

INSERT INTO sample_period_tb (start_time,end_time) VALUES (1192037400000,1192037700000);

The exception I get is this:

A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Waiting XID : {21215745, S} , APP, INSERT INTO sample_period_tb (start_time,end_time) VALUES
Granted XID : {18280645, S}
Waiting XID : {18280645, X} , APP, alter table "APP"."SAMPLE_PERIOD_TB" compress sequential
Granted XID : {18280645, S} , {21215759, S} , {21215745, S}
. The selected victim is XID : 21215745. 

This is horrible! I would have to stop all inserts or what?
If this improvement mean the problem would go away, let us know (and make it high priority!).
Otherwise, you may want to file a new bug!

> 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