[
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 fix.
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 ||
contextName.equals(USER_CONTEXT_ID));
*/
return(true);
}
> Same value returned by successive calls to a sequence generator flanking an
> unorderly shutdown.
> -----------------------------------------------------------------------------------------------
>
> Key: DERBY-5494
> URL: https://issues.apache.org/jira/browse/DERBY-5494
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2,
> 10.9.0.0
> 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
