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 (Commented) (JIRA)" <ji...@apache.org> on 2012/04/11 01:33:16 UTC
[jira] [Commented] (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=13251176#comment-13251176 ]
Mike Matrigali commented on DERBY-5493:
---------------------------------------
I will review these changes more carefully in next few days, this comment is just based on your comment describing the changes. Did you
understand why this approach fixes DERBY-5494 vs the subtransaction approach? In the normal sub transaction case I was thinking
that it should wait on locks and return too much contention on a lock timeout, to take care of a expected very short lock waits
if 2 threads are trying to update the sequence at same time, but maybe the 1 transaction per sequence makes this impossible to happen.
What is the expected behavior of creating a sequence, with respect to autocommit and locking? Is the create done in the nested transaction
and autocommitted?
A comment I meant to make before, is that DERBY-5495 requires crash testing, and now there is a framework to do that in junit tests -
see store/OCRecoveryTest.java, basically there is a routine to fork out a process to run a java test procedure and then you just exit which
will run through the "unclean" shutdown and next test connects running through whatever recovery will do on that unclean shutdown.
> 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
>
>
> 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