[
https://issues.apache.org/jira/browse/DERBY-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011534#comment-13011534
]
Mike Matrigali commented on DERBY-5151:
---------------------------------------
To me it seems like the discussion is upside down. It would be good to get a
clear description of what behavior of SEQUENCES is actually desired, and then
talk about implementation/syntax. Tweaking some syntax that tunes an
underlying knob doesn't really explain to a user what behavior is being
guaranteed.
current sequences are described by the sql standard such that implementations
can efficiently execute concurrently in a multi-user scenario - and thus there
are no transactional guarantees on "holes".
Some of the requirements I am not understanding are what kind of cross thread
performance are you looking for as a tradeoff on minimizing holes. What is the
actual expectation of setting cache to 1. It obviously currently has the
effect of not losing as many values on shutdown, but is an application using it
guaranteed anything? I would like to
understand what the system is committing to if the various syntaxes are
supported. Not only for what the system happens to do today but what it might
need to support in the future if we look to do work to make SEQUENCES perform
better in the future.
> Sequence without cache
> ----------------------
>
> Key: DERBY-5151
> URL: https://issues.apache.org/jira/browse/DERBY-5151
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Mark Holster
> Attachments: sequence-no-cache.patch
>
>
> Currently, a sequence in Derby always uses a pre allocating cache. I'm
> working on an usecase which requires a number to increase with a fixed value.
> The usecase fails after a restart because of the pre allocating cache.
> I've created a patch that adds the options CACHE | NO CACHE to the create
> sequence statement. When no cache is provided, the pre allocating cache size
> will be set to 1, which results in a "no cache sequence".
> I've followed the CYCLE | NO CYCLE code as much as possible. Tested it in my
> own app and it seems to work fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
