[
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
