[
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.
Thanks,
-Rick
> 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
>
>
> 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
