[
https://issues.apache.org/jira/browse/DERBY-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256413#comment-13256413
]
Kristian Waagan commented on DERBY-5494:
----------------------------------------
I noticed this code in the commit mail:
+++
db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/xact/XactFactory.java
Tue Apr 17 18:40:15 2012
@@ -943,12 +943,18 @@ public class XactFactory implements Tran
public boolean flushLogOnCommit(String contextName)
{
//
- // if this is a user transaction, flush the log
+ // if this is a user transaction, flush the log by default.
+ // if this is a nested user update transaction, flush log by default.
// if this is an internal or nested top transaction, do not
// flush, let it age out.
+ //
+ // In all cases log will not be flushsed by Xact.prepareCommit()
+ // if commitNoSync() has been called rather than commit.
//
- return (contextName == USER_CONTEXT_ID ||
- contextName.equals(USER_CONTEXT_ID));
+ return (contextName == USER_CONTEXT_ID ||
+ contextName.equals(USER_CONTEXT_ID) ||
+ contextName == NESTED_UPDATE_USER_CONTEXT_ID ||
+ contextName.equals(NESTED_UPDATE_USER_CONTEXT_ID));
}
It appears that reference equality is used as an optimization, i.e. to avoid
calling equals in many/some cases. With that in mind, would it make sense to
group the == together first, and then the equals next?
Also, a comment on the use of == for string comparison wouldn't hurt.
> 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
> Assignee: Mike Matrigali
> Labels: derby_triage10_9
> Attachments: derby-5494_diff_1a.txt, derby-5494_diff_2.txt
>
>
> 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
