Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 29 Apr 2014 01:08:16 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12710537.1398426821380.196019.1398733696776@arcas>
In-Reply-To: <JIRA.12710537.1398426821380@arcas>
References: <JIRA.12710537.1398426821380@arcas>
Subject: [jira] [Commented] (DERBY-6554) Too much contention followed by
 assert failure when accessing sequence in transaction that created it
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rick Hillegas commented on DERBY-6554:
--------------------------------------

I'm going to try the following approach unless people think that this won't work. The idea is to add a special code path for the situation when we are trying to use the sequence generator in the transaction which created it:

1) When the CreateSequenceConstantAction creates a sequence, it will mark the associated SequenceUpdater with its execution TransactionController's transaction id (what comes back from getTransactionIdString()) plus an as yet not implemented commit/rollback counter obtained from the TransactionController. If someone can think of a better identifier for the execution transaction, I'm happy to use that.

2) When trying to update the sequence number on disk, the SequenceUpdater will check to see whether the current execution transaction is the one it was marked with. If so, we will use the execution transaction rather than a nested subtransaction to do the work.

3) When TransactionController.commit() or abort() is called, we will bump the commit/rollback counter.

There may be an edge-case on an edge-case to consider: creating and using a sequence inside the nested transaction context of a stored procedure.

Your feedback is welcome.

Thanks,
-Rick

> 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: 10.9.1.0, 10.11.0.0, 10.10.2.0
>            Reporter: Knut Anders Hatlen
>
> {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
(v6.2#6252)