db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5151) Sequence without cache
Date Sat, 26 Mar 2011 01:31:05 GMT

    [ 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

View raw message