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 Tue, 27 Mar 2012 16:42:28 GMT

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

Rick Hillegas commented on DERBY-5493:

Thanks for the quick analysis, Mike. Some responses follow:

>o yet another system catalog, now we would have 2 for sequences

More files are bad, I understand. But this would be similar to adding another index on syssequences,
which is well within the bounds of what we do during a feature release.

> o A hidden system catalog is going to present even more problems for users if there is
a problem with it.  How do run maintenance on it if necessary.  How do you tell if there is
a problem with it?

Another valid question. I see it as being similar to the property conglomerate. How do we
do maintenance on the property conglomerate? With SYSGHOST there is a diagnostic VTI for inspecting
it and looking for problems, so I think we are in a better situation than we are with the
property conglomerate.

>o I can't tell from the patch description, but previous description of this approach seemed
to be funneling all sequence work to a single  thread/transaction.  This is the wrong architectural
direction for derby, we should always be looking to spread this work across many threads,
as does current implementation where work is done in the user thread.

It's true that everything happens in a single transaction controller. However, a thread switch
does not happen. Instead, a context manager is pushed and popped around the use of the shared
transaction controller. It's also true that calls to the GhostController are synchronized,
which will single-thread access to SYSGHOST. We could introduce a separate transaction controller
per sequence and synchronize on those sequence-specific transaction controllers. The additional
single-threading introduced by the current patch funnels all pre-allocation requests for all
sequences through the same chokepoint. This might be an issue for an application which has
small pre-allocation ranges and many sequences. I don't know how typical that usage will be
or whether it is worth the extra complexity of more transaction controllers.

>o brand new boot time work.  I would rather not add sql layer garbage collection to the
architecture. I know there are existing applications that boot quite often, and any additional
work at boot time will cause the performance issues.  

I doubt that this extra boot cost will be measurable. However, we could add an initial tuple
to SYSGHOST which would flag whether there was any boot-time work to do. This would reduce
the extra boot cost to one page read.


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