[
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
