You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/04/17 20:55:18 UTC
[jira] [Issue Comment Edited] (DERBY-5493) Same value returned by
successive calls to a sequence generator.
[ 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