[
https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239591#comment-13239591
]
Mike Matrigali commented on DERBY-5493:
---------------------------------------
i will spend some time commenting more in full, but wanted to post a quick
response. I do not think the extra complexity being proposed
in the patch is warranted, I may be missing the benefits of the implemented
patch. In the end I think we are adding hidden conglomerates, extra boot time
work, more database activity to handle
one case where user queries the system catalogs directly causing problems for
that transaction. I don't know why users are doing this. I see
that this patch includes some new derby specific interfaces, that maybe will
stop users from doing that. For all other cases I believe there
are much easier changes that don't require such complex changes.
My problems with that solution:
o yet another system catalog, now we would have 2 for sequences
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?
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.
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.
> 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
