Return-Path: 
 <dev-return-16861-apmail-phoenix-dev-archive=phoenix.apache.org@phoenix.apache.org>
X-Original-To: apmail-phoenix-dev-archive@minotaur.apache.org
Delivered-To: apmail-phoenix-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 7BD4D18958
	for <apmail-phoenix-dev-archive@minotaur.apache.org>;
 Wed,  6 May 2015 23:51:42 +0000 (UTC)
Received: (qmail 24781 invoked by uid 500); 6 May 2015 23:51:42 -0000
Delivered-To: apmail-phoenix-dev-archive@phoenix.apache.org
Received: (qmail 24724 invoked by uid 500); 6 May 2015 23:51:42 -0000
Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@phoenix.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@phoenix.apache.org>
List-Post: <mailto:dev@phoenix.apache.org>
List-Id: <dev.phoenix.apache.org>
Reply-To: dev@phoenix.apache.org
Delivered-To: mailing list dev@phoenix.apache.org
Received: (qmail 24713 invoked by uid 99); 6 May 2015 23:51:42 -0000
Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 23:51:42 +0000
Received: from localhost (localhost [127.0.0.1])
	by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org)
 with ESMTP id E9CCC181BBF
	for <dev@phoenix.apache.org>; Wed,  6 May 2015 23:51:41 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org
X-Spam-Flag: NO
X-Spam-Score: 0.77
X-Spam-Level: 
X-Spam-Status: No, score=0.77 tagged_above=-999 required=6.31
	tests=[KAM_ASCII_DIVIDERS=0.8, RCVD_IN_MSPIKE_H3=-0.01,
	RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled
Received: from mx1-us-west.apache.org ([10.40.0.8])
	by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new,
 port 10024)
	with ESMTP id mjeNF0nAwNOr for <dev@phoenix.apache.org>;
	Wed,  6 May 2015 23:51:01 +0000 (UTC)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with
 SMTP id 24CB32A4A3
	for <dev@phoenix.incubator.apache.org>; Wed,  6 May 2015 23:51:01 +0000 (UTC)
Received: (qmail 22409 invoked by uid 99); 6 May 2015 23:50:59 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 23:50:59 +0000
Date: Wed, 6 May 2015 23:50:59 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: dev@phoenix.incubator.apache.org
Message-ID: <JIRA.12827869.1430956193000.30559.1430956259766@Atlassian.JIRA>
In-Reply-To: <JIRA.12827869.1430956193000@Atlassian.JIRA>
References: <JIRA.12827869.1430956193000@Atlassian.JIRA>
 <JIRA.12827869.1430956193986@arcas>
Subject: [jira] [Commented] (PHOENIX-1954) Reserve chunks of numbers for a
 sequence
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/PHOENIX-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531711#comment-14531711 ] 

Lars Hofhansl commented on PHOENIX-1954:
----------------------------------------

[~jesse_yates], [~jfernando_sfdc], [~elilevine], FYI.

> Reserve chunks of numbers for a sequence
> ----------------------------------------
>
>                 Key: PHOENIX-1954
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1954
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>
> 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)