db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5494) Same value returned by successive calls to a sequence generator flanking an unorderly shutdown.
Date Wed, 11 Apr 2012 23:01:16 GMT

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

Mike Matrigali commented on DERBY-5494:

I am not sure yet how to fix, but think I understand the issue now.  At least as far back
as 10.1, the system always does a no sync commit for any transaction that is not a user transaction.
 I don't think this is a problem for anything other than sequences, but welcome opinions.

The comments in the code are correct but incomplete, I think the code was written before there
were any nested user transactions.  the 
internal and nested top transactions are store internal things that do not require flushing.
 I am guessing since this code was added
we added the 2 new nested transactions, for the sql layer.

I hacked the code below to always return true and the test case worked, but this is not correct

An easy fix that might work is to return true for user transactions and NestedRawUpdateUserTransaction.
 The problem with this change is it will
slow down  operations that use NestedRawUpdateUserTransaction but not require forcing the
log on commit.

The system already has commit and
commitNoSync interfaces, so I think the right longterm fix would be to get rid of this code
completely and change all the callers to correctly call
commit or commitNoSync.  

The problem code is in xactfactory.java and then is called by Xact.java:
        Decide if a transaction of this contextId needs to flush the log when
        it commits
    public boolean flushLogOnCommit(String contextName)
        // if this is a user transaction, flush the log
        // if this is an internal or nested top transaction, do not
        // flush, let it age out.
        return (contextName == USER_CONTEXT_ID ||
> Same value returned by successive calls to a sequence generator flanking an unorderly
> -----------------------------------------------------------------------------------------------
>                 Key: DERBY-5494
>                 URL: https://issues.apache.org/jira/browse/DERBY-5494
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,,,,,
>            Reporter: Rick Hillegas
>              Labels: derby_triage10_9
> The following sequence of steps causes a sequence generator to return the same value
on successive NEXT VALUE FOR calls.
> 1) Bring up ij and issue the following commands:
> connect 'jdbc:derby:db;create=true';
> create sequence s;
> values next value for s; 
> 2) Control-c out of ij so that the engine comes down hard without an orderly shutdown.
> 3) Now bring up ij again and issue the following commands:
> connect 'jdbc:derby:db';
> values next value for s; 
> Thanks to Knut for finding this one.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message