[ https://issues.apache.org/jira/browse/PHOENIX-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621522#comment-14621522 ]
James Taylor commented on PHOENIX-1954: --------------------------------------- Thanks, [~jfernando_sfdc]. Couple of minor things, then I think we're good to go: 1) I think there are a couple more calls that use Sequence.ValueOp.RESERVE_SEQUENCE in PhoenixStatement. I think they all should be changed to Sequence.ValueOp.VALIDATE_SEQUENCE (given the race condition you found). Maybe we should just remove the RESERVE_SEQUENCE enum? 2) It looks like you'd always be throwing here and thus always be making an RPC at validate time. Shouldn't this be calling isSequenceCacheExhausted() instead? {code} - public long incrementValue(long timestamp, ValueOp op) throws SQLException { + public long incrementValue(long timestamp, ValueOp op, long numToAllocate) throws SQLException { SequenceValue value = findSequenceValue(timestamp); - if (value == null) { + if (value == null || SequenceUtil.isBulkAllocation(numToAllocate)) { throw EMPTY_SEQUENCE_CACHE_EXCEPTION; } + if (value.currentValue == value.nextValue) { if (op == ValueOp.VALIDATE_SEQUENCE) { return value.currentValue; } throw EMPTY_SEQUENCE_CACHE_EXCEPTION; - } - return increment(value, op); + } + return increment(value, op, numToAllocate); } {code} > Reserve chunks of numbers for a sequence > ---------------------------------------- > > Key: PHOENIX-1954 > URL: https://issues.apache.org/jira/browse/PHOENIX-1954 > Project: Phoenix > Issue Type: New Feature > Reporter: Lars Hofhansl > Assignee: Jan Fernando > Attachments: PHOENIX-1954-rebased.patch, PHOENIX-1954-wip.patch, > PHOENIX-1954-wip2.patch.txt, PHOENIX-1954-wip3.patch, > PHOENIX-1954-wip4.patch, PHOENIX-1954-wip5-rebased.patch, > PHOENIX-1954-wip6.patch > > > In order to be able to generate many ids in bulk (for example in map reduce > jobs) we need a way to generate or reserve large sets of ids. We also need to > mix ids reserved with incrementally generated ids from other clients. > For this we need to atomically increment the sequence and return the value it > had when the increment happened. > If we're OK to throw the current cached set of values away we can do > {{NEXT VALUE FOR <seq>(,<N>)}}, that needs to increment value and return the > value it incremented from (i.e. it has to throw the current cache away, and > return the next value it found at the server). > Or we can invent a new syntax {{RESERVE VALUES FOR <seq>, <N>}} that does the > same, but does not invalidate the cache. > Note that in either case we won't retrieve the reserved set of values via > {{NEXT VALUE FOR}} because we'd need to be idempotent in our case, all we > need to guarantee is that after a call to {{RESERVE VALUES FOR <seq>, <N>}}, > which returns a value <M> is that the range [M, M+N) won't be used by any > other user of the sequence. My might need reserve 1bn ids this way ahead of a > map reduce run. > Any better ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)