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] [Commented] (DERBY-6554) Too much contention followed by assert failure when accessing sequence in transaction that created it
Date Sat, 10 May 2014 21:58:49 GMT

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

Mike Matrigali commented on DERBY-6554:

thanks rick for the explanation, i keep forgetting about the shutdown and cache eviction case.
 I'll think about
it some more while you are out.  But early thoughts would be to take incremental steps so
as to not hold
up your sequence work any more:

1) go with your patch #1 above as it seems to do what you need and passes tests.  I think
it only slows
    down delete row reclamation with extra exceptions vs returns, so probably ok.  I am ok
with the one
    store change for now as an incremental step.

2) file a separate JIRA to put in self deadlock detection in for waiting locks.  With your
patches the
    code is available and work just needs to be done on problems with rest of code.

3) file a separate JIRA to change 0 wait locks to not throw an exception in self deadlock.
 This will need
    a solution that works for sequences.  Not sure of solution at this point, would be easy
if we can have
    sequences wait.   

4) test and see if we think sequences would benefit from waiting.   If so figure out how to
wait.  Current
    lock interfaces don't make it easy to set timeout's other than 0 and default.  
    I think we want sequences to wait at least as long as we expect another transaction
    to take to update the sequence and commit the transaction on a system that does a real
I/O at commit
    time.   If waiting does not work out, may still want to try sleep retry now that we know
we are not
    in self deadlock vs. sending an error to user.  All depends on doing this without negatively
    the shutdown and cache clean cases.

I would be interested in working on #2, as it ties in with work I would like to do to improve
space reclamation.  I think some of the problems in this area are with self deadlock and waiting
help.  It would be easier to work on this if we separated the dependencies.  Along with #2
I would look
at all the store nested transactions and make sure they are ready and do the right thing with
deadlock.  I may need help with the language layer uses, but I don't think there are many
other than
sequences and identity.

> Too much contention followed by assert failure when accessing sequence in transaction
that created it
> -----------------------------------------------------------------------------------------------------
>                 Key: DERBY-6554
>                 URL: https://issues.apache.org/jira/browse/DERBY-6554
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,,
>            Reporter: Knut Anders Hatlen
>         Attachments: D6554.java, D6554_2.java, derby-6554-01-aa-useCreationTransaction.diff,
derby-6554-01-ab-useCreationTransaction.diff, derby-6554-01-ac-useCreationTransaction.diff,
derby-6554-01-ad-bugfixes.diff, derby-6554-02-aa-selfDeadlock.diff, derby-6554-02-ab-selfDeadlock.diff,
derby-6554-02-ac-selfDeadlock.diff, derby-6554-02-ae-selfDeadlock_sps_compress.diff, derby-6554-02-af-askToRaiseSelfDeadlock.diff,
> {noformat}
> ij version 10.11
> ij> connect 'jdbc:derby:memory:db;create=true' as c1;
> ij> autocommit off;
> ij> create sequence seq;
> 0 rows inserted/updated/deleted
> ij> values next value for seq;
> 1          
> -----------
> ERROR X0Y84: Too much contention on sequence SEQ. This is probably caused by an uncommitted
scan of the SYS.SYSSEQUENCES catalog. Do not query this catalog directly. Instead, use the
SYSCS_UTIL.SYSCS_PEEK_AT_SEQUENCE function to view the current value of a query generator.
> ij> rollback;
> ERROR 08003: No current connection.
> ij> connect 'jdbc:derby:memory:db' as c2;
> ij(C2)> autocommit off;
> ij(C2)> create sequence seq;
> 0 rows inserted/updated/deleted
> ij(C2)> values next value for seq;
> 1          
> -----------
> ERROR 38000: The exception 'org.apache.derby.shared.common.sanity.AssertFailure: ASSERT
FAILED Identity being changed on a live cacheable. Old uuidString = 0ddd00a9-0145-98ba-79df-000007d88b08'
was thrown while evaluating an expression.
> ERROR XJ001: Java exception: 'ASSERT FAILED Identity being changed on a live cacheable.
Old uuidString = 0ddd00a9-0145-98ba-79df-000007d88b08: org.apache.derby.shared.common.sanity.AssertFailure'.
> {noformat}

This message was sent by Atlassian JIRA

View raw message