Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 10 Apr 2012 21:37:16 +0000 (UTC)
From: "Rick Hillegas (Updated) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <728826394.9682.1334093836335.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1354085544.6625.1320674331736.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-5493) Same value returned by successive
 calls to a sequence generator.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-5493:
---------------------------------

    Attachment: derby-5493-01-ad-simplerApproach.diff

Attaching derby-5493-01-ad-simplerApproach.diff. This patch is not ready for commit. I want to run some throughput tests with it first. The patch implements the approach which we seem to have converged on:

1) Retains the syscs_peek_at_sequence() function so that users can get the instantaneous value of a sequence without having to query SYSSEQUENCES. I changed the signature of this function. Instead of a single uuid argument, the function now takes a schema and sequence name pair. The idea here is to not tempt users into driving this function with a select from SYSSEQUENCES in order to get the uuid.

2) Instead of using an invisible conglomerate, pre-allocation happens in the SYSSEQUENCES row (as in 10.8).

3) Pre-allocation is done by a transaction which is dedicated to the sequence. The transaction expects to do its work immediately, without waiting for a lock, and then to autocommit that work. If the transaction can't get a lock immediately, it raises a TOO MUCH CONTENTION exception. We seem to agree that TOO MUCH CONTENTION can only arise if sequence DDL is in flight or if the application scans SYSSEQUENCES against our advice.

I tried a slightly different approach at first. In that approach, pre-allocation happened in a sub-transaction of the session's execution transaction. That approach fixed this bug (DERBY-5493) but did not fix DERBY-5494. By using a separate, dedicated transaction, I am able to fix DERBY-5494 as well.

Touches the following files:

--------------

M       java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java
M       java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
M       java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java
M       java/engine/org/apache/derby/catalog/SystemProcedures.java

Support for the new syscs_peek_at_sequence() function.

--------------

M       java/engine/org/apache/derby/loc/messages.xml
M       java/shared/org/apache/derby/shared/common/reference/SQLState.java

I changed the wording of the TOO MUCH CONTENTION exception so that it points the user at the likely cause of the problem: an open scan of SYSSEQUENCES. I changed this exception to Transaction severity so that the language layer does not get confused during cleanup.

--------------

M       java/engine/org/apache/derby/impl/sql/catalog/SequenceUpdater.java

Re-plumbed the SequenceUpdater as described above.

--------------

M       java/engine/org/apache/derby/impl/sql/catalog/SequenceGenerator.java

Adjusted the wording of some comments.

--------------

M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/GeneratedColumnsHelper.java
M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/SequenceGeneratorTest.java
A       java/testing/org/apache/derbyTesting/functionTests/tests/lang/t_5494.sh
M       java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java

Tests for the new system function and to verify the fixes to the correctness problems.

--------------

M       java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_2.java
M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesTest.java
M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/GrantRevokeDDLTest.java
M       java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java
M       java/testing/org/apache/derbyTesting/functionTests/master/ij7.out

Tests which had to change to account for the new system function.

                
> 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