db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5493) Same value returned by successive calls to a sequence generator.
Date Wed, 11 Apr 2012 13:29:16 GMT

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

Rick Hillegas commented on DERBY-5493:

Thanks for your comments and your offer to review this patch, Mike. Some comments inline...


>Did you understand why this approach fixes DERBY-5494 vs the subtransaction approach?

I don't understand why the subtransaction approach fails. I have attached a revised repro
to DERBY-5494. That shows the behavior in the current trunk without this patch. The sequence
generator durably commits a change to SYSSEQUENCES, which can be seen by another thread. The
system-crash reverses this supposedly durable change. The same behavior can be seen in
(except that the size of the pre-allocation range is shorter so the second thread sees a slightly
different value before the crash).

I decided to try a dedicated transaction because I knew, from the ghost conglomerate experiment,
that that approach fixed DERBY-5494.

The only variable that I can see is the use of a subtransaction vs the use of an ordinary
transaction. You are the expert in the implementation and use of subtransactions. Do you have
any theories about what is going on?

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

The 1 transaction per sequence should make this impossible for the cases which I thought we
wanted to support. Waiting for the lock would support the following additional use-cases,
but I thought that we agreed they were not worth supporting:

a) Dropping a sequence and then rolling back that transaction.

b) Scans of SYSSEQUENCES by the application.

>What is the expected behavior of creating a sequence, with respect to autocommit and locking?
Is the create done in the nested tr nsaction and autocommitted?

Nothing has changed in the CREATE SEQUENCE logic. That work happens in an ordinary user transaction,
just as it did in 10.8. At the end of this comment, I attach a script which shows that if
you create a sequence and a table but don't commit that work, then another thread will timeout
trying to use those objects.

This is the behavior which I thought we agreed: DDL happens in ordinary user transactions.
It is just the NEXT VALUE FOR which happens in an unusual transaction. Note that SYSCS_PEEK_AT_SEQUENCE
doesn't actually do any transactional work, it just looks at an in-memory value via a synchronized

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

Great! I will look into making a proper JUnit test out of java/testing/org/apache/derbyTesting/functionTests/tests/lang/t_5494.sh.



Here is the script which demonstrates the behavior of uncommitted ddl:

connect 'jdbc:derby:memory:db;create=true' as dbo;

call syscs_util.syscs_set_database_property( 'derby.locks.waitTimeout', '2' );

autocommit off;

create sequence foo;
create table t( a int );

connect 'jdbc:derby:memory:db' as otheruser;

-- times out waiting for the other thread's ddl to commit
values next value for foo;
select * from t;

set connection dbo;


set connection otheruser;

-- succeeds
values next value for foo;
select * from t;
> 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:,,,,,
>            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


View raw message