db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (DERBY-5493) Same value returned by successive calls to a sequence generator.
Date Tue, 17 Apr 2012 18:55:18 GMT

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

Mike Matrigali edited comment on DERBY-5493 at 4/17/12 6:53 PM:
----------------------------------------------------------------

I committed a fix for DERBY-5494.  I was going to try to do some more performance tests, but
turns out my windowsXP laptop has write cache enabled, and I can't seem to get it turned off
as the control box is greyed out.  I am going to find another machine
but figured since all tests pass, it would be better to get code in trunk so you can work
off it, and we can see full effect of both
changes.   I expect the 5494 change to have a 
negative affect on performance of sequences.  The worst case will be 1 thread, preallocation=0
(or 1 I don't know which gives you no preallocation).  I would assume less and less affect
the larger the preallocation, or more users.

I would not be surprised if the throughput goes back to same problem you were seeing with
user transaction vs nested transaction, now that the nested user transaction will wait on
the commit like the user transaction.  If all threads need to wait for the preallocation unit
of work step, and we now have added a synchonous I/O to that process, then would expect throughput
to drop.  
                
      was (Author: mikem):
    I committed a fix for DERBY-5494.  I was going to try to do some more performance tests,
but turns out my windowsXP laptop has write cache enabled, and I can't seem to get it turned
off as the control box is greyed out.  I am going to find another machine
but figured since all tests pass, it would be better to get code in trunk so you can work
off it, and we can see full effect of both
changes.   I expect the 5494 change to have a 
negative affect on performance of sequences.  The worst case will be 1 thread, preallocation=0
(or 1 I don't know which gives you no preallocation).  I would assume less and less affect
the larger the preallocation, or more users.
                  
> Same value returned by successive calls to a sequence generator.
> ----------------------------------------------------------------
>
>                 Key: DERBY-5493
>                 URL: https://issues.apache.org/jira/browse/DERBY-5493
>             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: Rick Hillegas
>              Labels: derby_triage10_9
>         Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff,
derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff, derby-5493-01-af-usersubtran.diff
>
>
> The following script shows the same value being returned from a sequence generator by
two successive NEXT VALUE FOR calls. Thanks to Knut for finding this:
> connect 'jdbc:derby:memory:db;create=true';
> create table t (x int);
> create sequence s;
> autocommit off;
> select count(*) from sys.syssequences with rs;
> values next value for s;
> drop table t;
> rollback;
> -- same value as previous call
> values next value for s; 

--
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

        

Mime
View raw message